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Fejezet 1
Bevezetes
A szam togepen futo programokat ket csoportba szokas osztani: a rendszerprogramok
csoportjara, es a felhasznaloi programok csoportjara. A rendszerprogramok kozul a
legalapvet}bb az operacios rendszer. Ennek feladata egyreszt az, hogy eltakarja a bonyo
olult hardver elemek programozasat a programozo el}l, masreszt pedig ez a szoftver felel}s
o
o
a hardver er}forrasoknak a programok kozti elosztasaert, az egyes hardver er}forrasok
o
o
vedelmeert.
Az operacios rendszerek az utobbi evtizedekben nagyon nagy fejl}desen mentek
o
keresztul. Az els} generacios szam togepekben meg nem hasznaltak operacios rendo
szereket. Megjelenesuk a masodik generaciohoz kot}dik: a bonyolultabb hardver
o
rendszerekre egyre bonyolultabb operacios rendszereket ep tettek, majd megjelent a
multiprogramozas, a mai operacios rendszerek egy lapvet} fontossagu tulajdonsaga.
o
A multiprogramozasnak ket valtozata van: a tobbtaszkos (multitasking) illetve a
tobbfelhasznalos (multi user) rendszer (ez a ket forma nem zarja ki egymast). A
tobbfelhasznalos rendszerekben egy kozponti egysegen osztozik tobb felhasznalo, de a
kozponti egyseg nagy sebessege miatt minden felhasznalo ugy erzi, hogy egy sajat gepe
van, amin dolgozik. A tobbtaszkos rendszer annyit tud, hogy ott egy felhasznalo egyszerre tobb feladatot ind that el, es az elind tott feladatok egyszerre (parhuzamosan) fognak
vegrehajtodni.
Az operacios rendszerekkel kapcsolatban a jelenlegi kutatasok a halozati operacios
rendszerek koreben tortennek. Ezekben a rendszerekben a szam togepek valamilyen drottal ossze vannak kapcsolva, es a felhasznalo az operacios rendszer seg tsegevel
ezeken a drotokon keresztul adatokat vihet at az egyik gepr}l a masikra az egyik
o
gepr}l (mondjuk Magyarorszagrol) bejelentkezhet egy masik szam togepre (peldaul
o
Kanadaba), es Magyarorszagrol ugy dolgozhat, mintha kozvetlenul a kanadai szam togep
egy keperny}jen dolgozna. Az, hogy az altala begepelt karakterek illetve a vegeredmenyek
o
milyen modon jutnak el t}le Kanadaba (es onnan vissza Magyarorszagra) rejtve marad
o
el}le. A kommunikacio tortenhet akar telefonvonalakon, akar m}holdon keresztul - a
o
u
lenyeg az, hogy az informacio eljusson az egyik helyr}l a masikra. Az operacios rendo
szer feladata ilyenkor az, hogy a megb zhatatlan, rossz min}seg} telefonvonalakon egy
o u
megb zhato kommunikacios csatornat biztos tson a felhasznaloknak, amiben az egyik
gepr}l a masikra kuldott adatok "nem kallodnak el", es az adatokat a fogado allomas az
o
elkuldes sorrendjeben kapja meg.
Eddig mar szamtalan sok operacios rendszer keszult, mindegyik mas cellal, mas
problemakor megoldasara. Ma a legelterjedtebb ilyen rendszerek (tobbek kozt): az
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FEJEZET 1. BEVEZETES

OS/360, a CP/CMS, a VAX VMS, a UNIX es az MS-DOS. Mar eleg id} volt aho
hoz, hogy a legfontosabb absztrakcios szintek es szolgaltatast pusok kialakuljanak.
Ezek a szolgaltatasok a hagyomanyos operacios rendszerekben ket f} temakorbe sorolo
hatok: folyamatokkal (processzekkel) kapcsolatos, es a fajlokkal kapcsolatos absztrakcios
eszkozok. A tovabbiakban ezekr}l lesz szo kicsit reszletesebben.
o

1.1 Folyamatok
A folyamat (processz) de n cioja UNIX kornyezetben a kovetkez}keppen adhato meg:
o
folyamatnaktekinthetunk minden egyes futo programot - az altala lefoglalt memoriavales
egyeb er}forrasokkal egyutt. (Gyakran hasznaljak hasonlo ertelemben a taszk elnevezest
o
is.) Az operacios rendszer minden egyes futo programrol bizonyos informaciokat tarol
egy un. processz-tablaban. A folyamatokkal kapcsolatban ket alapvet} m}velet van:
o u
uj folyamat letrehozasa, es egy futo folyamat megall tasa (abortalasa, lelovese). Ha egy
folyamat letrehoz egy uj folyamatot, akkor az ujonnan letrehozott folyamatot gyermek
folyamatnak nevezik, azt a folyamatot, amely a gyermeket letrehozta szul} folyamatnak
o
nevezik. Fontos megoldani az egymassal parhuzamosan futo folyamatok egymas kozti
kommunikaciojat is.
Minden egyes folyamathoz tobbek kozt hozza van rendelve egy egyedi un. folyamatazonos to (processz-id, pid), es az, hogy ki ind totta el azt a folyamatot (vagyis az,
hogy melyik felhasznalo ind totta el persze az is tarolva van minden egyes folyamatrol,
hogy melyik folyamat hozta letre, es meg sok mas adat). Ilyen jelleg} informaciok nyu
ilvantartasa erdekeben minden egyes felhasznalohoz hozza van rendelve egy termeszetes
szam, a felhasznalo azonos toja (user-id, uid). A folyamatot elind to felhasznalo uid-je
be lesz jegyezve a processz-tablaba, es kes}bb ha kell, akkor onnan ki lehet azt nyerni.
o
A UNIX operacios rendszerben alapertelmezes szerint minden egyes folyamat orokli a
szul}jenek az uid-jet es a jogait valamint szamos mas jellemz}jet is. (Ezzel szemben a
o
o
folyamat-azonos to, a pid peldaul nem orokolhet}, mert ekkor az nem lenne egyedi.)
o
Az egymassal parhuzamosan m}kod} folyamatoknak gyakran kell kommunikalniuk
u o
valamilyen modon. Az operacios rendszer feladatai koze tartozik a folyamatok kozotti
kommunikacio (Interprocess Communication) megszervezese is.
Sok operacios rendszer a folyamat fogalmat ket f} reszre osztja: egy taszkra es egy
o
vagy tobb un. threadre (magyarul: szal). A taszk egy "er}forrasgy}jtemeny" (fajlok,
o
u
memoriateruletek es mas objektumok) a thread pedig a folyamat "lelke": lenyegeben
egy processzor-allapotbol es egy sajat stack-b}l all. Egy taszkban egy vagy tobb thread
o
lehet. Az eredeti (UNIX-szer}) modellben egy folyamat pontosan egy taszkbol es egy
u
benne futo threadb}l all.
o
(Szokas megkulonboztetni preempt v ill. nem preempt v thread-rendszereket is.
Az el}bbiben minden egyes threadnek van egy-egy id}szelete, am g futhat, majd ha az
o
o
lejar, akkor egy masik thread kapja meg a CPU-t az utobbi modellben a threadnak
valamilyen op-rendszer rendszerh vas megh vasaval onszantabol kell lemondania a CPUhasznalatrol - ez utobbi forma a program nyomkovetesekor hasznos.)
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1.2 Fajlok
Minden szam togepet felszerelnek valamilyen hattertarral, ami adatokat kepes tarolni
hosszabb id}n keresztul (fajlok "formajaban"). Ezeknek a fajloknak neveket adhatunk.
o
Az, hogy a nev hany es milyen karaktert tartalmazhat, nagyon elter} lehet a kulonboz}
o
o
operacios rendszerekben. A fajlok kezeleset vegz} operacios rendszer komponenseket
o
gyakran h vjak fajlrendszer kezel}nek.
o
Egy kisebb meret} UNIX rendszerben alaphelyzetben kb. 3000-10000 kisebb-nagyobb
u
fajl van a hattertaron, ezert az ott tarolt fajlokat valahogyan rendszerezni kell. A
kialakult legelfogadhatobb megoldast a hierarchikus directory-szerkezet (directory
szo jelentese katalogus) jelenti. Ekkor a valamilyen szempont szerint osszetartozo fajlok
kerulnek egy kozos directoryba. A hierarchikussag abban all, hogy minden egyes directory tartalmazhat un. aldirectorykat, amik szinten tartalmazhatnak aldirectorykat
...
Az egyetemeken ez peldaul ugy hasznalhato ki, hogy a felhasznalokat ket csoportba
osztva (pl. oktatok csoportjaba ill. hallgatok csoportjaba persze lehet sok mas csoport,
ez inkabb csak pelda ertek}) mindket csoportnak egy-egy kulon directoryja lehet, gy a
u
hallgatok fajljai vedve vannak a k vancsi oktatok el}l (es termeszetesen ford tva is).
o
A hierarchikus directory-szerkezetet biztos to operacios rendszerekben az egyes
fajlokra ugy hivatkozhatunk, hogy el}szor meg kell adni azt, hogy a fajlt tartalmazo
o
directoryt melyik directorykon keresztul erhetjuk el a hierarchikus directory-szerkezet
gyokeret}l kiindulva, majd meg kell adni a fajlt tartalmazo directory nevet es maganak
o
a fajlnak a nevet is. (Ezt nevezik a fajl pathname-jenek.) Ha peldaul van egy user nev}
u
directory (tegyuk fel, hogy ez a directory a directory-szerkezet gyokereben van), aminek
van egy student nev} aldirectoryja, akkor az abban az aldirectoryban lev} xyz nev}
u
o
u
fajlra a /user/student/xyz nevvel hivatkozhatunk. (A UNIX operacios rendszerben a
pathname egyes tagjait a / jel valasztja el egymastol, es a fajlnevben a legels} / jel a
o
hierarchia tetejen lev} un. gyoker-directoryt jeloli, amely egyetlen mas directorynak sem
o
aldirectoryja.) Ha minden egyes fajlra csak ilyen "hosszu modon" (un. abszolut pathname seg tsegevel) hivatkozhatnank, akkor nagyon nehez lenne az elet (es kenyelmetlen
is!). Ezert alak tottak ki a munka-directory (working directory) fogalmat. Ez azt jelenti, hogy van egy un. munka-directory, amelyben a fajlokat a gyokert}l hozzajuk vezet}
o
o
minden egyes aldirectory nevenek felsorolasa nelkul erhetjuk el. Csak azoknak a directoryknak a nevet kell felsorolni, amely a hierarchiaban a munka-directory alatt van. (Az
ilyen, a munkadirectorybol kiindulo pathname-eket relat v pathname-nek szokas nevezni.)
Meg egy fontos elv van a fajlrendszerekkel kapcsolatban: a keszulekfuggetlenseg.
Eszerint az elv szerint a programokat ugy kell meg rni, hogy m}kodni tudjanak attol
u
fuggetlenul, hogy az inputjukat es az outputjukat kepez} fajlok egy oppy-lemezen vagy
o
egy winchesteren vannak (vagy esetleg az input a billenty}zetr}l lesz beadva ...).
u o
Egyes operacios rendszerek a fajlokrol nem felteteleznek semmifele bels} strukturat:
o
egyszer}en egy byte-folyamnak tekintik azokat (ilyen a UNIX). Mas rendszerekben a
u
fajlok mondjuk x vagy valtozo szamu byteot tartalmazo rekordok sorozata - ez gyakori
volt a lyukkartyas id}szakban: minden fajl 80 byteos rekordokbol allt. Ma egyre inkabb
o
a byte-folyam jelleg} fajl kep kerul el}terbe, es a fajlok bels} szerkezetet pedig az azt
u
o
o
feldolgozo programok "sajat belatasuk szerint" alak thatjak ki.
A fajlokhoz minden operacios rendszer nyilvantart bizonyos un. fajl-attributumokat.
Ezek a fajllal egyutt a hattertaron lesznek tarolva. Ilyen fajl-attributumok peldaul a
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kovetkez}k (nem minden operacios rendszer ad lehet}seget az itt felsorolt osszes fajlo
o
attributum nyilvantartasat):
a fajl merete byteban VAGY blokkban (operacios rendszert}l fugg a "VAGY" ..)
o
a fajl hozzaferesehez szukseges jelsz}
o
a fajl maximalis merete (nehol ez is el}re meg van kotve)
o
a fajl tulajdonosanak azonos toja
a fajl "system" fajl-e (az operacios rendszerenkent valtozhat, hogy egy fajl
"system"-sege milyen lehet}segeket jelent)
o
a fajl "archive" fajl-e (ez az egyik operacios rendszer szer} eszkozben, az MS-DOSu
ban azt jeloli, hogy a fajl ki van-e mentve (BACKUP-olva) vagy sem)
a fajl "hidden"-e vagy sem
a fajl leterehozasanak datuma
a fajl utolso modos tasanak datuma
utolso "hasznalat" datuma
a fajl jelszavakat tartalmaz, nem nezheti meg senki (esetleg meg a rendszergazda
sem)
a fajl egy aldirectory (ilyenkor gyakran az adott aldirectory altal tarolt fajlok neveit
tartalmazza ...)
esetleg azt is tarolhatja a rendszer egy fajlrol, hogy a fajl a hattertar hibas szektorait
(bad blocks) is tartalmazza, ezert nem tanacsos hozzanyulni.
Sok operacios rendszer a fajlokat vagy legalabb egy reszuket hasznalatuk kozben a
memoriaban tartja. Ezt cache-elesnek nevezik, es a memorianak azt a (gyakran dinamikusan valtozo meret}) reszet, amit az operacios rendszer erre felhasznal cacheu
memorianak nevezik.
Sok fajlrendszer lehet}seget nyujt a fajlok "memoriaba agyazasara" (memory
o
mapped les). Ez azt jelenti, hogy a folyamatok a memoria valamelyik szegmensen
(reszen) keresztul a fajlba tudnak rni, illetve onnan tudnak olvasni: ha a program a
memoriaszegmens 0., 1., 2. ... bytejat mondjuk megvaltoztatja, akkor vele egyutt meg
fog valtozni a hattertarolon tarolt fajl 0., 1., 2. ... byteja is. Ez a megoldas tehat
egysegesse teszi a fajl- es memoriahozzaferes modjat, kapcsolatot teremtve az operacios
rendszer fajlrendszere es a memoriakezel} komponense kozott.
o
Az operacios rendszer feladata a fajlrendszer konzisztenssegenek a biztos tasa
is: ez peldaul magaba foglalja azt is, hogy az operacios nehogy ketszer ugyanazt a diszkszektort hasznalja fel egy fajl kulonboz} reszeinek a tarolasara, mert gy adatok vesznenek
o
el.

1.3. MEMORIAKEZELES

11

1.3 Memoriakezeles
A memoria az egyik legfontosabb (es gyakran a legsz}kosebb) er}forras, amivel egy
u
o
operacios rendszernek gazdalkodnia kell f}leg a tobbfelhasznalos rendszerekben, ahol
o
gyakran olyan sok es nagy folyamat fut, hogy egyutt nem fernek be egyszerre a
memoriaba. A memoriakezelesr}l nem lesz szo a kes}bbi fejezetekben, ezert itt iso
o
mertetem a fontosabb fogalmakat.
Am g a multiprogramozas nem jelent meg, addig az operacios rendszerben nem volt
olyan nagy szukseg a memoriakezel} reszekre. A multiprogramozas megjelenesevel azono
ban szuksegesse valt a memorianak a futo folyamatok kozotti valamilyen "igazsagos"
elosztasara. A megoldast a virtualis memoriakezeles jelentette. Ez ugy m}kodik,
u
hogy az operacios rendszer minden egyes folyamatnak ad a kozponti memoriabol egy
akkora reszt, amelyben a folyamat meg ugy ahogy m}kodik, es a folyamatnak csak
u
azt a reszet tartja a kozponti memoriaban, amely eppen m}kodik. A folyamatnak azt
u
a reszet, amelyre nincs szukseg (mert peldaul mar reg nem adodott ra a vezerles, es
feltetelezhetjuk, hogy rovid id}n belul nem is fog vegrehajtodni) ki kell rakni a hattertarra
o
(a diszken az un. lapozasi teruletre). Ez a megoldas azert m}kodik, mert a prou
gramok legtobbszor egy eljarason belul ciklusban dolgoznak, nem csinalnak gyakran nagy
ugrasokat a program egyik veger}l a masikra (ez a lokalitas elve).
o
A kozponti egyseg fel van szerelve egy ugynevezett memoriakezel} egyseggel
o
(MMU), amely gyeli, hogy olyan kodreszre kerul-e a vezerles, amely nincs benn a
kozponti memoriaban (mert peldaul a hattertarra van kirakva). Ha a memoriakezel}
o
egyseg azt talalja, hogy ez az eset all fenn, akkor az operacios rendszert arra utas tja,
hogy rakja ki a hattertarra a folyamatnak azt a reszet, amely jelenleg a memoriaban van,
es azt a reszt hozza be a helyere, amelyre ezutan szukseg lesz.
A virtualis memoria kezelese leggyakrabban lapozassal (paging) tortenik. Ekkor
a virtualis memoria (egy folyamat virtualis c mtartomanya, amit a CPU biztos t) fel
lesz osztva egyenl} nagysagu reszekre, un. lapokra (pages) - a hattertar es a memoria
o
kozott legalabb ennyi byteot fog az operacios rendszer atvinni (vagy ennek tobbszoroset).
A zikai memoria pedig fel lesz osztva ugyanolyan meret} lapkeretekre (page frames).
u
Ha mondjuk a virtualis c mtartomany 128 KByte, es 64 KByte zikai memoria van
a szam togepbe ep tve, akkor ez 32 lapot, es 16 lapkeretet jelent, ha a lapmeret 4
KByte. Ha egy program vegrehajt egy olyan (gepi kodu) utas tast, amely a memoria
valamelyik rekeszere hivatkozik (a hivatkozott memoriarekesz c met nevezik virtualis
c mnek), akkor ezt a c met el}szor a processzor atadja az MMU-nak, ami majd egy
o
zikai memoriabeli c met all t el} bel}le. E feladatanak ellatasahoz az MMU tarol egy
o o
un. laptablat (vagy legalabbis valamilyen modon hozzafer a laptablahoz), amely a
lapok es lapkeretek egymashoz rendeleset tartalmazza egy specialis un. "ervenyessegi"
bittel, ami minden egyes laphoz tarolva van, es a bit erteke azoknal a lapoknal 1, amelyekhez tartozik a zikai memoriaban lapkeret. Az MMU m}kodese soran egy kapott
u
virtualis c mhez tartozo laprol megvizsgalja, hogy az "ervenyessegi" bitje 1-e. Ha igen,
akkor a megadott laphoz tartozo lapkeret sorszamat visszaadja a CPU-nak (mondjuk
... ez tortenhet gy is), es az a k vant adatot a megfelel} ( zikai memoria-) rekeszb}l
o
o
megszerzi (vagyis azt csinal vele, amit a gepi kodu programban a vegrehajtott gepikodu
utas tasban megadtak). Mi tortenik akkor, ha az "ervenyessegi" bit 0? Ekkor egy un.
hardware-interrupt (megszak tas) keletkezik, amit laphibanak (page faultnak) neveznek.
Ekkor kerul vegrehajtasra az operacios rendszer memoriakezel} resze, ami egy masik
o
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"ervenyes" ( zikai memoriabeli) lapnak az 1-es ervenyessegi bitjet 0-ra all tja, es a hozza
tartozo lapkeretet a diszkre menti (az un. lapozasi teruletre). A lapkeretet ezutan be rja
a laptablaba ahhoz a laphoz, amelyhez a laphiba soran hozza akartak ferni, betolti a diszkr}l (lapozasi teruletr}l) a megfelel} laphoz tartozo lapkeret tartalmat, a laphoz tartozo
o
o
o
"ervenyessegi" bitet 1-re all tja, es az MMU ezutan mar laphiba nelkul el tudja vegezni
a c mtranszformaciot.
Tobb programnak szuksege lehet esetleg tobb virtualis c mtartomanyra is. Sok CPU
lehet}seget ad szegmentalt memoriakezelesre, ami annyit jelent, hogy a program
o
tobb un. szegmensben is tarolhat adatokat, es mindegyik szegmenshez kulon-kulon
laptabla tartozhat (mondjuk ... de ez nem mindig van gy). Minden szegmensnek van egy
dinamikusan valtoztathato merete, ami az adott szegmensben megengedett legmagasabb
sorszamu memoriarekeszt adja meg. Ilyen rendszerekben a memoria c mzesekor meg kell
adni egy szegmens-sorszamot es az azon beluli virtualis c met is. Ilyen CPU-kon gyakori
az is, hogy az operacios rendszer rovid id}re nemcsak egy-egy lapot, hanem egy egesz
o
szegmenst visz ki a hattertarra - lenyegeben azt nevezik swappingnek.
A fenti le ras alapjan mar megerthet} a virtualis memoriakezeles lenyege, de azt
o
fontos megeml teni, hogy ez a valodi (m}kod}) operacios rendszereknek az egyik legbonyu o
olultabb resze, es nagyon nehez egyeb szempontoknak is megfelel}, raadasul hatekony
o
memoriakezel}t rni.
o

1.4 A shell
Az operacios rendszerekhez tartozik a felhasznaloval (interakt v) kapcsolatot tarto
parancsertelmez}, a shell (igaz nem olyan szorosan, mint az el}bbi pontokban eml tett
o
o
reszek). A legegyszer}bb shellek csak annyit tudnak, hogy egy tetsz}leges programot
u
o
el tudnak ind tani (peldaul azt a programot, amelyiknek a nevet a felhasznalo a billenty}zeten beadta). A bonyolultabb shellek pedig akar egy komplett programnyelvet
u
nyujtanak a programozo szamara (ilyen shell peldaul a REXX, vagy a UNIX shelljei).

1.5 Vedelem
A vedelem nagyon fontos, f}leg a tobbfelhasznalos operacios rendszerekben. Itt kell
o
vedeni a felhasznalokat egymas el}l, es az operacios rendszer "bels} dolgait" a (k vancsi,
o
o
rosszindulatu, ugyetlen) felhasznalok, es a hibas programok el}l. A vedelem alapjat az
o
kepezi, hogy a legtobb mikroprocesszor ketfele uzemmodban tud m}kodni: felhasznaloi
u
illetve felugyel}i uzemmodban. A felugyel}i uzemmodban minden meg van engedve, a
o
o
felhasznaloi uzemmodban nehany dolog nincs megengedve (peldaul az, hogy az egyik
felhasznalo at rja a masik felhasznalo programjat, es a felhasznalok nem nyulhatnak az
operacios rendszer "beleegyezese nelkul" a kulonfele hardver periferiakhoz). A felugyel}i
o
uzemmod fenn van tartva az operacios rendszernek, a felhasznaloi uzemmodban pedig az
egyes felhasznalok programjai futhatnak.

1.6 INPUT/OUTPUT
Az operacios rendszer f} feladatai koze tartozik az is, hogy vezerelje a szam togephez
o
kapcsolt I/O periferiakat. A periferiakat ket csoportba szoktak osztani: blokk-
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eleres}ek es karakter-eleres} ek. Az els} csoportba tartoznak azok, amelyeknel a
u
u
o

hardver periferia elemi m}veletenek egy blokk (nagyobb adatterulet mondjuk 512 byte
u
vagy annak a tobbszorose) beolvasasat ill. ki rasat lehet tekinteni, es az egyes blokkok
"c mezhet}k".
o
A karakter-eleres}ek csoportjaba tartoznak azok, amelyeknel az elemi m}veletnek az
u
u
egy darab karakter ki rasa ill. beolvasasa tekinthet} - itt peldaul "poz cionalasra" eleve
o
nincs lehet}seg. Ez a felosztas nem a legjobb, de lenyegeben megfelel}. Peldak blokko
o
eleres} periferiakra: oppy-disk, winchester, RAM-diszk. Karakter-eleres} periferiak:
u
u
billenty}zet, RS232-vonal, eger, printer. Az operacios rendszereknek azon reszeit, ameu
lyek a hardver periferiak kezeleseert felel}sek, eszkozmeghajtoknak (device drivereknek)
o
nevezik.

1.7 Operacios rendszerek bels} szerkezete
o
Az operacios rendszer bels} szerkezete tobbfele lehet: peldaul monolitikus, retegzett
o
(layered), virtualis gepeken alapulo valamint a kliens-szerver modellen alapulo.
A monolitikus operacios rendszer (mint peldaul a UNIX) magja egyetlen programbol
all. Ebben a programban az eljarasok szabadon h vhatjak egymast, a koztuk lev} komo
munikacio eljarasparametereken es globalis valtozokon keresztul zajlik.
A retegzett szerkezet} operacios rendszer magja tobb modulbol all, es a modulok
u
kozott egy export-import hierarchia gyelhet} meg: minden modul kizarolag a hieraro
chiaban alatta lev} modul interfeszet hasznalja.
o
A virtualis gepeken alapulo operacios rendszerben kozponti reszen helyezkednek el
a virtualis gepeket menedzsel} (hypervisor) rendszerrutinok. Ez a program lehet}ve
o
o
teszi a hardver er}forrasainak (CPU, diszk, periferiak, memoria, ...) tobb operacios
o
rendszer kozotti hatekony elosztasat. A hypervisor leggyakrabban a szam togep hardveret "tobbszorozi meg" ugy, hogy a rajta futo operacios rendszerek azt higgyek, hogy
ovuke az egesz gep (pedig "csak" egy virtualis gepen futnak). Ha peldaul egy hardvermegszak tas generalodik, akkor ez a szoftver adja at annak a virtualis gepnek, amelyre
ez tartozik (az, hogy kire tartozik egy hardver-megszak tas, tobbfelekeppen eldonthet}:
o
peldaul az alapjan, hogy a kerdeses I/O eszkozt ki hasznalta utoljara). Ilyen hypervisor
peldaul az IBM VM/370. Az altala letrehozott es irany tott virtualis gepek az IBM /370es hardver "pontos masolatai", es tudnak futtatni (egymastol fuggetlenul) AIX, CMS,
TSO es mas operacios rendszereket.
A kliens-szerver modellen alapulo operacios rendszerek eseteben az operacios rendszer
kozponti magja altalaban egy un. mikrokernel, es maga az operacios rendszer itt tobb
parhuzamosan futo folyamatbol all. Mindegyik folyamat az operacios rendszer valamely
jol elkulon thet} reszet valos tja meg (peldaul lehet egy vagy akar tobb fajlszerver folyao
mat, egy diszkvezerl}, egy printervezerl} folyamat a rendszerben). Ezeknek a folyamao
o
toknak valamilyen kommunikacios eszkozt kell biztos tani, es ez a mikrokernel egyik f}
o
feladata (a memoriakezelesen k vul). A legtobb ma hasznalt ilyen kernel az uzenetatadast
(message passing) teszi lehet}ve a parhuzamosan m}kod} folyamatok kozotti kommuo
u o
nikacio elvegzese erdekeben. Az alacsonyszint} uzenetatadas m}kodhet ket teljesen
u
u
kulonboz} host kozott is ugyanugy, mint egy hoston belul kulonboz} folyamatok kozott,
o
o
ami a kommunikacio formajat egysegesse teheti egy gepen belul es ket gep kozott (ezt a
transzparenciat nagyon nehez elerni).
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1.8 Osztott rendszerek architekturaja
Manapsag a szam togepes halozatok orasi utemben fejl}dnek { a nagysebesseg} halozatok
o
u
egyre olcsobbak lesznek (peldaul a 100 megabit/sec atviteli sebesseg} Ethernet mar
u
sok helyen felvaltja az eddig alkalmazott 10 megabit/sec-es Ethernetet, es egyre tobb
helyen alkalmaznak (mikro)processzorok adatvonalainak kozvetlen osszekapcsolasan alapulo halozati adatatviteli technologiat), es ezzel parhuzamosan egyre olcsobban egyre
gyorsabb mikroprocesszorokat fejlesztenek ki a hardverfejleszt}k laboratoriumaiban. Eno
nek a fejl}desnek egy nagyon fontos kovetkezmenye az, hogy mod van nagyteljes tmeny}
o
u
mikroprocesszorok nagysebesseg} halozaton keresztul torten} osszekotesere (ezzel osztott
u
o
rendszerek1 letrehozasara). Ma mar kialak tottak tobb(t z)ezer mikroprocesszorbol allo
szam togepes rendszereket, de ezek kozul nem viselheti mindegyik az osztott rendszer
nevet, mivel az alapszoftvere nem biztos tja a felhasznalo fele a kell} mertek} transzo
u
parenciat, vagyis a felhasznalo akarva-akaratlanul is szembetalalkozik olyan { peldaul
folyamatok szinkronizaciojaval kapcsolatos { problemakkal, amiket az okoz, hogy a rendszer nem egyetlen processzoron van implementalva.
Manapsag az osztott rendszerek alkalmazasanak szamos el}nye van, es a jelenleg
o
m}kod} megvalos tasok problemai miatt szamos hatranya is akad.
u o
Az osztott rendszerek alkalmazasa mellett szolnak az alabbi tenyez}k:
o
gazdasagossaguk (peldaul a hasonlo teljes tmeny} szuperszam togepekkel szemben)
u
a veluk elerhet} tenyleges feldolgozasi kapacitas oriasi merteke (a legtobb rendszer
o
teljes tmenye a bekapcsolt processzorok szamanak linearis fuggvenye)
az egesz rendszer megb zhatosaganak, elerhet}segenek novekedese
o
Ahogyan az osztott rendszerek mellett talaltunk szamos okot arra, hogy alkalmazasukat barkinek ajanlhassuk, ugy talalhatunk tobb olyan tenyez}t is, ami a jelenlegi
o
osztott-rendszer technologia alkalmazasa ellen szol:
a megfelel} transzparencia hianya
o
a rendszer komponensei kozti kapcsolatot biztos to adatatviteli kozeg (vagyis a
halozat ) megb zhatosaga nagyban befolyasolja a rendszer alkalmazhatosagat2
egy osztott rendszer er}forras-adminisztracioja (itt nem a rendszergazda feladao
tok ellatasara gondolok, hanem peldaul a fajlok es mas operacios rendszer
er}forrasokra) sokkal er}forrasigenyesebb az egyes komponensek osszekapcsolatlan
o
o
allapotbeli adminisztraciojanal
Az osztott rendszerek hardware komponenseit kepez} szam togepeket szokas mulo
ticomputer illetve multiprocesszor halmazra felbontani aszerint, hogy a processzoraik
:::

1 De n cio: osztott rendszeren egy olyan tobbprocesszoros rendszert ertek, amely tobb (akar kozos
memoriaval nem rendelkez}) szam togepen m}kodik, de a rendszer felhasznaloja megis ugy latja, mintha
o
u
az egesz rendszer egyetlen nagyteljes tmeny} szam togep lenne. (Itt a felhasznalo elnevezes alatt nemcu
sak a klasszikus ertelemben vett felhasznalokat ertem (akik a rendszerre kesz tett alkalmazoi programokat
hasznaljak), hanem azokat a programozokat is, akik a rendszerre uj programokat fejlesztenek.)
2 Az Ethernet halozatokban peldaul nem lehet id} tekinteteben fels} korlatot adni arra, hogy egy adatcsoo
o
magot egy szam togep mikor tud a droton tovabb tani (annak ellenere, hogy mernokok valosz n}leg be tudjak
u
bizony tani, hogy annak a valosz n}sege 1 (HF: tenyleg mennyi ez a valosz n}seg?), hogy egy adatcsomagot
u
u
egy szam togep korlatos id}n belul el tud kuldeni), ezert az Ethernet altalaban nem hasznalhato valos idej}
o
u
elosztott rendszerek kesz tesere.
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rendelkeznek-e kozos hasznalatu memoriaval vagy sem. A multiprocesszor eseten van
ilyen kozos hasznalatu memoria.
A szoftver tekinteteben pedig szokas beszelni lazan kapcsolt rendszerekr}l ilo
letve szorosan kapcsolt rendszerekr}l (az el}bbiekben csak egy-egy rendszerkompoo
o
nens van elosztva a halozaton { ilyen peldaul a halozati fajlrendszer, az NFS, amelyben csak a fajlrendszer elosztott, es a rendszer tobbi komponense egymastol teljesen
fuggetlenul m}kodik, m g a szorosan kapcsolt rendszerekben nagyon keves az egymastol
u
fuggetlenul m}kod} komponens). A szorosan kapcsolt szoftverek tervezesekor a legnagyu o
obb nehezseget az okozza, hogy a rendszerben senki sem ismer globalis informaciokat a
rendszerr}l, mindig csak annak egy reszer}l (esetleg csak par t zezer szam togepr}l egy
o
o
o
millio szam togepet tartalmazo halozatban) vannak reszletes informaciok.
Megjegyezzuk, hogy a kommunikacio, a kommunikalo felek szerkezete nagyon
sokfele lehet az osztott rendszerekben. Ilyen teruleten is kialakultak mar "szokasos"
megoldasok: kliens-szerver parok kapcsolatat gyakran a tavoli eljarash vasi modellre ep tik (kett}nel) tobb komponens} rendszereket pedig gyakran az uzenetszorasra
o
u
(broadcasting) ep tik: itt az egyik resztvev} (rendszerkomponens) olyan eszkozokkel reno
delkezik, amivel egy uzenetet kuldhet az osszes tobbi resztvev}nek.
o

1.8.1 A tavoli eljarash vas

A helyi eljarash vas soran a h vo fel a h vott eljaras szamara atadando argumentumokat
altalaban a programvegrehajtasi veremre helyezi, majd atadodik a vezerles a h vott
eljarasnak, amely a veremr}l leolvashatja az argumentumokat, es elvegzi veluk a feo
ladatat. Miutat az eljaras befejez}dott, a vegeredmenyeket (a h vo eljarasnak viso
szaadando ertekeket) rarakhatja a veremre, es miutan a h vo eljaras visszakapja a
vezerlest, kiolvashatja a veremb}l az egyes visszateresi ertekeket, es felhasznalhatja azokat
o
tovabbm}kodese soran.
u
A tavoli eljarash vas soran a h vo es a h vott eljarasok nem feltetlenul ugyanazon a
szam togepen vannak: mialatt egy eljaras vegre lesz hajtva a tavoli gepen, addig a h vo
eljaras futasa felfuggeszt}dik (mondjuk a valasz visszaerkezeseig). A parameteratadas
o
megoldasara kialakultak mar elfogadhato technikak { ezzel majd egy kes}bbi kiadasban
o
reszletesebben fogunk foglalkozni.

1.8.2 Uzenetszoras

M g a tavoli eljarash vas altalaban a ketkomponens} kliens-szerver kapcsolatok impleu
mentalasara hasznalhato, addig az uzenetszoras ennel tobb komponens kapcsolatat (is)
kepes megteremteni. Termeszetesen kett}nel tobb rendszerkomponens kommunikacioja
o
megszervezhet} az egyes komponensek kozotti tavoli eljarash vasi m}veletekkel, de egy
o
u
ilyen esetben a kommunikacio lebonyol tasahoz szukseges tavoli eljarash vasok szama a
kommunikalo felek szamanal eggyel kevesebb, azaz azok szamanak novekedesevel egyenes
aranyban n}. Az uzenetszoras abban kulonbozik lenyegesen a tobb komponens kozott
o
elvegzett tavoli eljarash vas kozott, hogy alkalmazasakor az osszes c mzetthez egyetlen
m}velettel lehet az uzenetet elkuldeni.
u
Egy uzenet c mzettjeinek a halmazat csoportnak nevezzuk. Egy csoportot altalaban
folyamatoknak azon halmazabol alak tanak ki, amelyek valamilyen tekintetben azonosan
viselkednek. Szoftver tekintetben az azonos viselkedes egyik alapja a csoportok kozotti
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kommunikaciojanak azon tulajdonsaga, hogy a csoportnak kuldott uzenetek minden
csoport-tagnal megerkeznek, es az uzenetek megerkezesi sorrendje minden csoport-tagnal
ugyanaz. Most roviden attekintunk egy { az Amoeba elosztott operacios rendszerben implementalt { uzenetszorasi protokollt, amely megfelel a fenti kovetelmenyeknek
(vagyis ket tetsz}legesen kivalsztott uzenet egymashoz viszony tott sorrendje az osszes
o
szam togepen megegyezik).
Az algoritmus feltetelez egy koordinator szam togepet, amely a csoportok kommunikaciojanak koordinalasaert felel}s (amennyiben ez a szam togep elromlana, akkor a
o
protokoll uj koordinator valasztasat rja el} { ami peldaul az elosztott rendszerbe kapcsolt
o
szam togepek kozul valamilyen modon kivalaszthato { akar ugy is, hogy a legmagasabb
hardware-azonos toju hostot valasztjuk ki e celra).
Az algoritmus a kovetkez}keppen m}kodik:
o
u
1. Az uzenetszorassal elkuldend} uzenetet az uzenetszorast ker} folyamat atadja
o
o
az operacios rendszernek, ami gondoskodik a koordinatorhoz valo elkuldesr}l
o
(mondjuk egy hagyomanyos, tavoli eljarash vasra epul} eszkozzel), kiegesz tve egy
o
sorozatszammal (ami az eddig fogadott uzenetek sorozatszamanak maximumaval
kell, hogy megegyezzen).
2. A koordinator a kapott uzenetet a kovetkez}, az eddig hasznaltaknal eggyel
o
nagyobb uzenetsorszammal kiegesz tve a hardware nyujtotta { nem feltetlenul
megb zhato { uzenetszorasi eszkozzel mindenki szamara elkuldi az uzenetet.
3. Egy (broadcast) uzenet fogadasakor az uzenetet fogado szam togep operacios rendszer osszehasonl tja az uzenet sorszamat az eddig kapott uzenetek sorszamanak a
maximumaval. Ha a kapott uzenet sorszama nem csak eggyel nagyobb az eddigi
uzenetek sorszamanak maximumanal, akkor az operacios rendszer feltetelezheti,
hogy valamilyen oknal fogva egy (vagy tobb) uzenetet nem kapott meg { egyes
uzenetek nem jutottak el hozza (amik persze masokhoz mar eljuthattak). Amennyiben alapos a gyanuja annak, hogy egy uzenetet nem kapott meg egy adott
szam togep, akkor annak az uzenetnek az ujrakuldeset fogja kerni a koordinatortol.
Megjegyzesek:
A koordinatornak el kell tarolnia az osszes eddigi olyan uzenetet, amelyek ujrakuldeset
valamelyik folyamat meg kerheti (emlekezzunk ra, hogy a koordinatornak kuldott
uzenetek tartalmazzak az addig megkapott, legnagyobb sorszamu uzenet sorszamat).
Ha az uzenet kuld}je ugy latja, hogy a koordinator egy bizonyos id}n belul nem
o
o
tovabb totta (szorta szet ...) az uzenetet, akkor ujra kuldheti az uzenetszoras iranti
kerelmet a koordinatorhoz.
Minden uzenet el van latva egy egyedi azonos toval is a duplikatumok kisz}rese
u
celjabol.
Az is el}fordulhat, hogy az uzenet kuld}je nem az altala kuldott uzenetet kapja meg,
o
o
hanem el}bb nehany masikat, es csak aztan a sajatjat. Ez akkor lehet, ha tobben is
o
egyszerre akartak uzenetszorassal kommunikalni, es a koordinator egy masik uzenetet
kapott meg es tovabb tott el}bb.
o
Ha a koordinator szam togep osszeomlana, akkor uj koordinatort kell valasztani. Az uj
koordinatornak fel kell keszulnie esetlegesen uzenetek ujraadasara, gy az eddig elkuldott,
de mindenki altal nem megkapott uzeneteket az osszes potencialis koordinator-jeloltnek
el kell tarolnia.
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1.9 Holtpont
Lathato, hogy az operacios rendszernek nagyon nehez feladata az er}forrasok igazsagos
o
(es hatekony m}kodest eredmenyez}) kiosztasa. Ennek megoldasa gyakran lehetetlenseg,
u
o
mert nem ismert a folyamatok j}v}beli viselkedese (vagyis nem lehet tudni, hogy
oo
egy adott folyamatnak milyen er}forrasokra lesz meg szuksege). Vannak olyan
o
"megoszthatatlan" er}forrasok (mint peldaul a legtobb magnesszalag-egyseg), amelyet
o
egyszerre csak egy folyamat hasznalhat, es abbol adodhatnak a gondok, ha megis ket
folyamat probalja egyszerre hasznalni }ket. Tegyuk fel, hogy egy multitaskingot bizo
tos to operacios rendszerrel felszerelt gepen egy magnesszalag-egyseg van, es egy darab
printer. Ket folyamat fut, es mindkett} ki akar nyomtatni egy magnesszalagon tarolt fajlt.
o
Az egyik folyamat megnyitja a magnesszalag-fajlt (ezzel kizarolagos hozzaferesi jogot
nyer az egyseghez), a masik folyamat (multitaszkos volt a rendszer) ezzel parhuzamosan
megnyitja a nyomtatora irany tott fajlt (ezzel kizarolagos hozzaferesi jogot nyer a nyomtatohoz). Ekkor az els} folyamat megprobalhatja megnyitni a printer-fajlt, de mivel az
o
"foglalt", ezert kenytelen varni (folyamatosan), am g a masik folyamat "el nem engedi"
azt. A masik folyamat megprobalja megnyitni a magnesszalag-fajlt, de } is kenytelen
o
varni, am g a masik folyamat el nem engedi azt. Vagyis mindket folyamat olyan

esemeny bekovetkeztere var, amelyet a ket folyamat kozul A masik folyamat
idezhet el}. Az ilyen helyzeteket nevezik holtpont-helyzetnek, mas neven deadlocknak.
o
Leteznek ezt felismer} vagy megel}z} algoritmusok, de ezek az algoritmusok gyakran
o
oo
"kenyelmetlensegeket" okoznak a felhasznaloknak (pl. meg van kotve, hogy egy felhasznalo maximum hany folyamatot ind that el, mivel a processz-tabla is betelhet, es ez
is okozhat holtpontot), ezert tobb operacios rendszer (mint peldaul. a UNIX) egyszer}en
u
tudomast sem vesz arrol, hogy ez bekovetkezhet, es ha bekovetkezne egy ilyen esemeny,
akkor a felhasznalora b zza az ilyen helyzetbe kerult folyamatok "kiloveset" (ld. majd
kes}bb).
o

1.10 Az Intel 80386 mikroprocesszor architekturaja
Az Intel 80386-os mikroprocesszor egy olyan igazi 32-bites mikroprocesszor, amely a programozonak egy szegmentalt es lapozasos virtualis memoriat biztos t. Hardver modon
tamogatja a kulonfele vedelmi rendszerek kialak tasat (a programok 4 kulonboz} vedelmi
o
kategoriakba sorolhatoak, es az egyes kategoriakban a programok jogai eleg noman
szabalyozhatok). A 386-os nagyon jo alapot biztos t a UNIX operacios rendszer implementalasahoz, ezert erdemes a processzor architekturajat kozelebbr}l is megismerni.
o
Err}l lesz szo itt roviden.
o
A processzor memoriakezelesenek a lelket ket tablazat kore ep tik: ezek a tablak a
lokalis- es globalis le ro tablak (LDT: local descriptor table, GDT: global descriptor table). Ezek a tablak rjak le a szegmensek szerkezetet (peldaul a szegmens helyet
(bazisc met), meretet (lapokban vagy byteokban merve) es vedelmi jellemz}it). A GDTo
t minden program kozosen hasznalja, es a fontosabb rendszerszegmensek (mondjuk az
operacios rendszer szegmensei) erhet}k el ezen keresztul. Minden program rendelkezik
o
egy-egy sajat LDT-vel, amelyben a program sajat szegmensei vannak le rva - amelyek a
programkodot, adatokat es egyeb informaciokat tartalmazzak.
A processzornak 6 szegmensregisztere van: a CS, DS, SS, ES, FS es GS. Mindegyik szegmensregiszter egy 16-bites un. szelektor erteket tartalmaz, amely egyertelm}en
u
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azonos t egy-egy le rotablabeli elemet. (Pontosabban a 16 bitb}l 1 bit mondja meg, hogy
o
a lokalis vagy globalis deszkriptor tablarol van-e szo tovabbi 13 bit mondja meg, hogy az
adott tablan belul melyik sorszamu szegmensr}l van szo a maradek ket bit pedig vedelmi
o
informaciokat tartalmaz.) A szegmensregiszterek kozul a CS a kodszegmenst azonos tja
(vagyis azt a szegmenst, amely a vegrehajtando kodot tartalmazza), a DS az adatszegmenst (vagyis azt a szegmenst, ahonnan a program a futasahoz szukseges adatokat veheti), az SS pedig a program verem szegmenset azonos tja. A masik harom szegmenst
(ES, FS, GS) a programozo arra hasznalja, amire akarja - peldaul egyes utas tasok ele egyegy un. pre x byteot rva elerhet} az, hogy a processzor az adott utas tas vegrehajtasa
o
soran a DS szegmens helyett mondjuk az ES-t hasznalja az adatok eleresere.
Ezen k vul egy specialis kontroll-regiszter tartalmazza a laptabla kezd}c met a
o
memoriaban - ez alapjan tortenik az un. linearis c m zikai c mme konvertalasa (a 386-os
processzor 4 KByte-os lapokat kezel). A linearis c m kiszam tasa a kovetkez}keppen
o
tortenik: amikor egy program egy adott szegmens adott bytejara hivatkozik (a byte o szetjenek nevezik a byte szegmensen beluli helyet), akkor a processzor a szegmensszelektornak megfelel} le rotablaelemb}l a bazisc met es a bytehoz tartozo o szetet osszeadja,
o
o
es gy kapja meg az un. linearis c met. A lapozas termeszetesen letilthato (vagyis "kikapcsolhato"), es ekkor a linearis c m megegyezik a kerdeses byte zikai memoriabeli c mevel.
A processzor vedelmi modellje a kovetkez}: 4 un. logikai vedelmi gy} r} van (ezek
o
uu
kozul a 0-as sorszamu a legtobb privilegiumot biztos to, m g a 3-as sorszamu a legkevesebb
privilegiumot biztos to, un. legkevesbe privilegizalt gy}r}). Minden programrol tarolva
uu
van, hogy melyik gy}r}ben fut (ez az, amit a program nem valtoztathat meg), es minden
uu
egyes szegmeshez is tarolva van a deszkriptortablaban egy-egy ilyen privilegium-szint. A
legfontosabb szabaly az, hogy a program nem nyulhat bele a nalanal jobban privilegizalt
szegmensekbe. Egyeb esetekben un. (altalanos) vedelmi kizaras keletkezik, amikor az
operacios rendszer kapja meg a vezerlest, es a "sajat belatasa szerint" cselekedhet (mondjuk kil}heti a szabalytalankodo programot). A privilegizaltabb kodszegmensekben tarolt
o
eljarasok megh vasa is csak ellen}rz}tt modon tortenhet - csakis a deszkriptortablaban
o o
tarolt un. call-kapukon keresztul kerulhetunk privilegizaltabb kodszegmensbe. (Egy-egy
ilyen call-kapu (call gate) lenyegeben a privilegizaltabb szegmens "nyilvanos" belepesi
pontjait tarolja, es nem lehet csak ugy egy privilegizalt szegmens belsejebe "beleugrani".)
Ebben a pontban { folytatva a mikroprocesszor architekturak ismerteteset { az IBM
altal a 90-es evekben kifejlesztett Power mikroprocesszor architekturat fogom bemutatni.
Ez egy csokkentett utas taskeszlet} (RISC) processzor (az utas taskeszlet csokkentese az
u
egy utas tas ertelmezesere/dekodolasara szukseges id} csokkentese erdekeben hasznos {
o
ezzel "gyorsabb" lesz a processzor).
(majd egyszer ...)

1.11 Szabvanyok
A ny lt rendszerek "ny ltsaganak" az az alapja, hogy a kommunikaciojuk megfelel}en (szo
abvanyokban) rogz tett protokollok alapjan tortenik - ezek a szabvanyok teszik lehet}ve
o
a kommunikaciot. A ma kialakult szabvanyok nagyon sokret}ek es sokfajtak: rogz tik
u
azt, hogy az alapszoftvernek mit kell tudnia, az alapszoftver egyes moduljainak milyen
interface-ei legyenek (es meg sok mas dolgot).
A legismertebb alapszofvterrel kapcsolatos szabvanyok: a POSIX (Portable Operating System Inteface for UNIX) es az XPG3 (X/Open Portability Guide Volume 3),
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valamint letezik meg az AT&T altal kiadott SVID (UNIX System V Interface De nitions) szabvany is.
A SVID nyilvan az AT&T elkepzelesei alapjan keszult (a kialakult 4.3BSD UNIXszal szemben), a POSIX szabvanyok inkabb az AT&T es a 4.3BSD UNIX "metszete"
alapjan, m g az XPG3 inkabb az AT&T es a 4.3BSD UNIX "unioja" alapjan keszult el.
Termeszetesen ezek a szabvanyok sok nem a UNIX-szal kapcsolatos dolgot is tartalmaznak.
Most roviden osszefoglaljuk, hogy milyen ismertebb (gyakrabban hasznalt) komponensei vannak a POSIX operacios rendszer interfesz szabvanyoknak:

1003.1 : C konyvtari fuggvenyek { ide tartoznak a rendszerh vasok is, mivel azok

is a C konyvtaron keresztul erhet}k el.
o
1003.2 : Parancsertelmez}k es segedprogramok { vagyis ide tartozik az is, hogy
o
mit kell tudnia egy-egy shellnek.
1003.3 : Annak az ellen}rzesere modszerek, hogy egy rendszer illeszkedik-e a
o
POSIX szabvanyokhoz.
1003.4 : Valos-idej} rendszerekre vonatkozo szabvanyok (itt lehet id}beli
u
o
korlatokat is biztos tani a szolgaltatasokra).
1003.4a : Tobbszalu (multithreaded) alkalmazasok rasara vonatkozo szabvanyok.
1003.5 : Egy szabvanyos Ada konyvtar interfesz a POSIX-hoz.
1003.6 : Security { biztonsagossagi kerdesek vannak benne rogz tve.
1003.7 : Rendseradminisztracios lehet}segek.
o
1003.8 : (Halozati) transzparens fajleleres biztos tasa a POSIX-hoz.
1003.9 : Egy szabvanyos FORTRAN konyvtar interfesz a POSIX-hoz.
Fontos szerepe van a szabvanyos tasban (f}leg a programnyelvek es a szam togepes
o
halozatok teren) az ISO-nak (International Standards Organization) es az ANSI-nak (ez
a szervezet az ISO tagja).
Erdekes megeml teni, hogy az Internet vilaghalozatban hasznalt TCP/IP kommunikacios protokollok a nagy elterjedesuk miatt valtak de facto szabvannya, es ez mogott
nem a fenti "nagy" szabvanyos to szervezetek allnak.
Leteznek olyan szabvanyok is, amelyek egy adott processzort pusra leford tott
targykod hordozhatosagat akarjak biztos tani a kulonfele operacios rendszerek kozott.
Ilyen szabvany peldaul az iBCS2 (Intel Binary Compatibility Standard, 2. edition). A
legtobb 386-os PC-s UNIX megfelel ennek - ezert ezek a UNIX-ok egymas programjait
minden tovabbi nelkul kepesek futtatni. (Az iBCS2 nem csak ISA vagy EISA buszos
386-osokon (ill. 486-osokon) el! Pont ez a szep benne!)
Termeszetesen a ny lt rendszerek fogalmanem azonos a UNIX-szal, habar a ny lt rendszerekkel kapcsolatos (es elfogadott) szabvanyok legtobbszor UNIX-alapuak - a UNIX
rendszerb}l szarmaznak. Az OpenVMS operacios rendszer a DEC peldaja arra, hogy
o
nem UNIX-os kornyezetben is biztos thato a "ny lt rendszer" kep.
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1.12 Objektum-orientalt feluletek
Manapsag nagyon terjed}ben vannak az objektum-orientalt eszkozok illetve programozasi
o
nyelvek, viszont a legtobb szabvany illetve operacios rendszer szolgaltatas valamilyen
proceduralis (azaz nem objektum-orientalt) interfeszen keresztul all a programozok
rendelkezesere. Ezert sokan kesz tenek a mar meglev} proceduralis szemlelet} proo
u
gramkonyvtarakhoz olyan kiegesz teseket (un. "kopenyeket"), amelyek objektumorientalt szemlelet} hozzaferest biztos tanak az alatta lev} nem objektum-orientalt
u
o
felulethez (ezek a kiegesz tesek altalaban valamilyen objektum-orientalt nyelvi eszkozoket
(pl. orokl}des, osztalyok) biztos to programozasi nyelven keszulnek, mint peldaul a
o
C++ vagy az Objective-C). Az objektum-orientalt eszkozok el}nyei tobbek kozt az
o
ujrafelhasznalhato eszkozok tervezeseben ill. kesz teseben valamint az eszkozok { gyakran
{ konnyebb megerthet}segeben, megtanulhatosagaban rejlenek.
o
Eddig mar szamos kopenykesz tesi elv kialakult, itt most roviden attekintjuk ezeket.

1.12.1 Egyszer} kopeny
u

Akkor beszelunk egyszer} kopenyr}l, ha a kopeny az eredeti proceduralis felulethez
u
o
kepest nem nyujt gazdagabb szolgaltatasokat. Ezek a kopenyek gyakran ugy
keszulnek, hogy egy jol de nialt rendszerobjektum kore ep tik biztos tjak az adott
objektum letrehozasahoz illetve megsz}ntetesehez hasznalhato konstruktor illetve deu
struktor m}veleteket, valamint objektum-metoduskent biztos tjak az eredeti nem
u
objektum-orientalt felulet egyes m}veleteit (kiegesz tve esetleg konverzios m}veletekkel,
u
u
amik olyankor lehetnek szuksegesek, ha az eredeti nem objektum-orientalt felulethez
hozzaferni szandekozo konyvtarakat ezen objektum-orientalt feluletre ep tve akarunk
tovabbhasznalni).

1.12.2 Specializalt kopeny

Specializalt kopenyekr}l olyankor szokas beszelni, ha az altalunk letrehozott objektumo
osztalyok metodusai es az eredeti programozoi felulet eljarasai kozt nem lehet egy
egyertelm} megfeleltetest letes teni ilyenkor altalaban egy-egy osztalym}velet az ereu
u
deti proceduralis felulet tobb szolgaltatasat is igenybe veve igen osszetett feladatokat
lathat es lat is el. Altalaban nehezebb ilyen kopenyeket jol meg rni, viszont ezeket a
kopenyeket gyakran konnyebb felhasznalni, mint az egyszer} kopenyeket (ui. az egyszer}
u
u
kopenyeknel a kopeny hasznalojanak meg viszonylag jol kell ismernie az eredeti operacios
rendszer feluletet). Az is igaz, hogy ilyen specializalt kopenyeket jobban lehet igaz tani
az alkalmazas-fejleszt}k igenyeihez, ami szinten a kopeny hasznalojanak a lehet}segeit
o
o
konny ti.

1.12.3 Objektum-orientalt kopenyek tervezese

Az objektum-orientalt eszkozok (kopenyek) tervezesekor minden esetben azonos tani
kell a rendszerbeli er}forrasokat (objektum osztalyokat), valamint a rajtuk vegezhet}
o
o
m}veleteket. Operacios rendszerek eseten objektumok peldaul a folyamatok, a fajlok, a
u
memoria, stb. Ezeken pedig sokfele m}velet vegezhet} (amik termeszetesen operacios
u
o
rendszerenkent kulonboz}ek lehetnek). Miutan megvannak az objektum osztalyok,
o
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meg kell hatarozni a kapcsolatukat { a koztuk lev} esetleges orokl}desi relaciokat.
o
o
Fontos, hogy az objektum-orientalt kopenyek hibat}r}ek legyenek, az eredeti proceduralis
uo
felulethez kepest, vagyis csokkentsek a hibasan hasznalhato operacios rendszer eszkozok
szamat: seg tse a programozot a programhibak kikuszoboleseben valamint felder teseben.

1.13 Mi lesz meg
E rovid bevezet} utan a 2. es 3. fejezetben szo lesz a ma legelterjedtebb ny lt rendszo
ernek, a UNIX-nak a m}kodeser}l, es a legalacsonyabb szint} programozoi interfacer}l:
u
o
u
o
a rendszerh vasokrol. Az ezutan kovetkez} fejezetekben a ny lt rendszerek egymas kozti
o
kommunikaciojarol lesz szo tobb szempontbol is: a 4. fejezet a szam togepes halozatokat
mutatja be, valamint a legalacsonyabb szint} programozoi interfacet, amelyet halozati
u
alkalmazasok fejlesztesenel kihasznalhatunk: a Berkeley socketokat es az XTI-t (X/Open
Transport Interface).
A masodik fejezet nagyon keplekeny, most (1995-ben) mar nem is igazan tetszik
nekem, ezert varhatoan valtozni fog (bar ez a valtozas majd csak egy-ket kiadas elteltevel
fog realizalodni addig marad ez a megoldas).

1.14 Kerdesek, feladatok
1. Mi az operacios rendszer, es mi a feladata?
2. Mit jelentenek a kovetkez} fogalmak?
o
cache-memoria
gyermek-folyamat
taszk
processz-tabla
fajl
fajl-attributum
lap
lapkeret
paging
swapping
szegmens
multicomputer
multiprocesszor
3. Mit ertunk hierarchikus directory-szerkezeten?
4. Mit ertunk keszulekfuggetlensegen?
5. Mi a vedelem szerepe az operacios rendszerekben? Mit es ki el}l kell vedeni?
o
6. Mi a shell?
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7. Keressunk peldat olyan periferiara, amely nem teljesen illeszthet} be sem a blokko
eleres}, sem a karakter-eleres} periferiakrol alkotott kepbe!
u
u
8. Mi a virtualis memoriakezeles?
9. Mi a processzor memoriakezel} egysegenek a szerepe?
o
10. *Lehet-e egy (virtualis-) memoriakezel} egyseg nelkuli hardveren virtualis gepeket
o
szimulalni? Mi okozhat itt komoly problemat?
11. *Lehetne-e mondjuk egy Intel 80386-on virtualis 80386-os gepeket szimulalni? Ha
igen, akkor mit lehet mondani a szimulacio hatekonysagarol.
12. *A memoriaba agyazott fajlok hossza tobb operacios rendszerben is csak a processzor memoriakezel} egysegenek (MMU-nak) a lapmeretenek tobbszorose lehet.
o
Vajon miert? Milyen problemat akarnak gy kikuszobolni?
13. Miert fontos a fajlrendszer konzisztenciajanak biztos tasa?
14. Mi a holtpont es hogyan alakulhat ki?
15. Mit ertunk az osztott rendszer fogalom alatt?
16. Mi a lenyeges kulonbseg a szorosan illetve a lazan kapcsolt rendszerek kozott?

Fejezet 2
A UNIX operacios rendszer
A UNIX operacios rendszer els} valtozatat 1969-ben kesz tette el Ken Thompson az
o
AT&T-nel egy leselejtezett PDP-7 szam togepen. Miutan munkatarsai is jo lehet}segeket
o
lattak a programban, az AT&T szoftverfejleszt}inek egy resze elkezdett ezzel komolyabo
ban foglalkozni, es egyre ujabb, fejletteb valtozatokat hoztak ki. Mivel a UNIX rendszert
C nyelven kesz tettek, nagyon konny} volt at rni egy uj hardverre, ezert nagyon hamar
u
elterjedt az egesz vilagon. Elterjedeset seg tette az is, hogy az els} par evben a rendszer
o
teljes forraslistaja barki szamara (ingyen) hozzaferhet} volt. Ennek egy kovetkezmenye
o
volt az is, hogy a legtobb helyen az egyetemi oktatasban ezt a rendszert hasznaltak. A
UNIX hetedik valtozatanak megjelenese utan az AT&T latta a UNIX piaci sikeret, es a
forraskod mar csak a magas jogd jak meg zetese elleneben volt hozzaferhet}.
o
A UNIX legf}bb gyengesege az lett, hogy nagyon sok (tobbe-kevesbe elter}) valtozata
o
o
van. (Mar kialakult tobbfele szabvany, peldaul a SVID, amelyben azt speci kaljak, hogy
mit kell tudnia egy "igazi" UNIX-nak.) Ennek ellenere a UNIX alatt meg rt programok
sokkal hordozhatobbak, mint peldaul a DOS alatt meg rtak. A UNIX mar majdnem
minden szam togepre at lett rva (az IBM PC-t}l kezdve a szuperszam togepekig).
o
Az AT&T UNIX valtozata mellett jelent}s a BSD UNIX (Berkeley Software Distribuo
tion - ennek a jelenlegi (aktualis) valtozata a 4.4-es BSD UNIX), es a Microsoft XENIX
rendszere is.
A UNIX egy multitaskos es tobbfelhasznalos operacios rendszer, ezert alkalmas arra,
hogy az ilyen es ehhez hasonlo rendszerekben felmerul} problemakat ezen vizsgaljuk meg.
o

2.1 Nehany alapvet} UNIX-beli fogalom
o
A kovetkez} fogalmak ismeretere lesz szukseg:
o
uid: A felhasznalo azonos toja (a rendszernek minden egyes felhasznalonak egy
egyedi ilyen azonos toja van).
gid: Csoportazonos to. A UNIX rendszerben minden felhasznalo be van osztva egy
csoportba. A gid annak a csoportnak az azonos toja, amelybe a felhasznalo tartozik.
(A csoportbeosztas tetsz}leges lehet van olyan rendszer, ahol minden felhasznalo
o
egy kozos csoportba tartozik, es peldaul az egyetemeken gyakori a teachers illetve
students csoport.)
pid: Folyamat-azonos to.
23
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pgrp-id: Folyamat-csoport azonos toja. Ez egyenl} a folyamat-csoport vezet}jenek
o
o

a pid-jevel (minden folyamat tagja valamely folyamat csoportnak, minden folyamat
megalap that egy sajat folyamat-csoportot, es lehet}seg van peldaul egy folyamato
csoport minden tagjanak a "kilovesere" egyetlen m}velettel).
u

tgrp-id : Terminal group-id. Minden folyamathoz ez is tarolva van. Ez

egyenl} annak a folyamatnak a pid-jevel, amely a folyamathoz tartozo terminalo
(keperny})fajlt legel}szor megnyitotta. Ez altalaban a legel}szor elindult login
o
o
o
shell.

euid: (e ektiv user id) - altalaban egyenl} az uid-del, a felhasznaloi azonos tobval,
o

de bizonyos esetekben (un. setuid-bites programoknal) mas is lehet. Ilyen modon
egy adott folyamatnak tobb jogot lehet adni, mint ami a folyamat elind tojanak
van.

egid: (e ektiv group id) - mint euid, csak a csoport-azonos tora.
szuperfelhasznalo: minden jogokkal rendelkez} felhasznalo. A felhasznaloi
o
azonos toja altalaban 0 szokott lenni minden UNIX-ban, es felhasznaloi neve (login
neve) altalaban root.

2.2 Folyamatok a UNIX rendszerben
A UNIX rendszer egy igazi multitaskos rendszer, minden folyamat letrehozhat egy vagy
tobb gyermek-folyamatot, es a gyermek-folyamatok a szul}-folyamattal parhuzamosan
o
futnak. A gyermek-folyamat orokli a szul}jenek a jogait, es egyeb tulajdonsagait. A
o
processz-tablaban egy folyamathoz (tobbek kozott) a kovetkez} informaciok vannak
o
tarolva:
pid (folyamat azonos to )
pgrp-id (folyamat-csoport azonos to)
A szul}-folyamat azonos toja
o
A processzor-regiszterek ertekei
A folyamat altal elhasznalt CPU id}
o
A folyamat gyermek-folyamatainak a szama
A folyamatot elind to felhasznalo felhasznalo azonos toja es a csoportjanak az
azonos toja.
A folyamat e ektiv uid-je es gid-je (ezt ld. kes}bb)
o
A folyamat munka-directoryja (working directory)
A folyamat megnyitott fajljai
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(A folyamat kulcsfogalomnak szam t minden operacios rendszerben - nem csak a
UNIX-ban. Az, hogy mi tartozik egy folyamathoz nagyon nagy mertekben befolyasolja
az egesz operacios rendszer lehet}segeit es szerkezetet.)
o
Az operacios rendszer egy kicsi, de fontos resze a folyamat-utemez} (scheduler).
o
Mivel a legtobb UNIX-ot futtato hardveren csak egy processzor van, ezert ezen szimulalni
kell a folyamatok parhuzamos futasat. Ez pedig a kovetkez}keppen tortenik:
o
1. Az utemez} a futasra varo osszes folyamat kozul valamilyen szempont szerint
o
kivalaszt egyet, es atadja annak a vezerlest.
2. (Ha a folyamat valamikor a hattertarra kikerult, valamilyen virtualis memoriakezel} m}velet eredmenyekent, akkor el}bb visszahozza onnan.)
o u
o
3. A kivalasztott folyamat elkezd futni (vagyis megkapja a CPU-hasznalati jogot),
egesz addig, am g az un. id}szelete le nem jar. Ez azt jelenti, hogy ha a folyamat
o
id}szelete mondjuk 40 millisec., akkor a folyamat (kb.) 40 millisec.-ig fog futni.
o
4. Ha a folyamat id}szelete lejar, akkor ismet az utemez} kezd el m}kodni, az ujabb
o
o
u
folyamatot valaszt ki es annak adja at a vezerlest (vagyis vissza az 1. ponthoz).
A fentiekben az egyetlen problemas dolog az, hogy hogyan "jar le a folyamat
id}szelete" (vagyis egy folyamatnak onmaganak "le kell-e mondania" a processzorrol,
o
vagy pedig az id}szelet lejarta utan az operacios rendszer automatikusan el tudja-e venni
o
a folyamattol a processzorhasznalati jogot). A multitaskos rendszerekben legtobbszor a
masodik eset all fenn (a UNIX rendszereknel mindig). Ha az els} eset allna fenn, akkor
o
lehetne olyan folyamatot rni, amely sosem mond le a processzor hasznalatarol, es ezzel
a teljes operacios rendszer megbenulna, nem tudna ellatni a feladatat (az er}forrasok
o
igazsagos elosztasat).
Az Intel 8088-as mikroprocesszor eseten ez az ora-megszak tasok kihasznalasaval oldhato meg. Az IBM PC-ben van egy bels} ora, amely 1 masodpercben (kb. 100-szor) egy
o
un. ora-megszak tast general. Ennek a megszak tasnak van egy sorszama, tehat tartozik
hozza egyertelm}en egy megszak tas-vektor. Az operacios rendszert ilyen gepen ugy
u
rjak meg, hogy a megszak tas-vektor az utemez} modul memoriabeli c met tartalmazza,
o
es ilyen modon minden masodpercben kb. 100-szor, amikor a bels} ora "ut", akkor az
o
utemez} automatikusan megkapja a vezerlest es uj folyamatot valaszt ki.
o

2.3 A folyamatok kozotti kommunikacio (IPC) a
UNIX rendszerben

Kezdetben a UNIX csak a pipeokat tartalmazta mint IPC-eszkozt (ezt ld. kes}bb), ami
o
egy nagyon primit v eszkoznek bizonyult, mert a kommunikacio csak olyan folyamatok
kozott tortenhetett, amelyeknek van kozos }se. Az IPC mas eszkozei a UNIX rendo
szerbe csak a fejlesztesenek egy kes}i szakaszaban kerultek be, ezert az AT&T UNIX
o
(ezzel egyutt a Microsoft XENIX-e) es a BSD UNIX (ezzel egyutt peldaul az Ultirx)
rendszerek mas eszkozoket nyujtanak a programozok szamara az IPC megszervezesere.
Itt az AT&T UNIX altal nyujtott eszkozok lesznek bemutatva, mert kes}bb az lett
o
szabvanyos tva (az X/Open szabvanyba ez kerult be), igaz a masik tabor, a Berkeley
(BSD) UNIX fejleszt}inek csoportja ezt a tenyt mindmaig egyszer}en gyelmen k vul
o
u
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hagyta. (A legtobb BSD UNIX forgalmazo azert ad valamilyen konyvtarakat, amelyek az
AT&T rendszerh vasokat implementaljak vagy szimulaljak.) Az AT&T UNIX haromfele
eszkozzel rendelkezik ezen a teren: szemaforokkal, osztott memoriaval (shared memory) es uzenetatadassal (message passing).
A szemafor egy 0 es 32767 kozotti erteket vehet fel, es a programozo ennek az erteket
novelheti es csokkentheti ugy, hogy e ket m}velet oszthatatlan m} veletnek tekinthet},
u
u
o
vagyis az operacios rendszer gondoskodik arrol, hogy ne tudjak ketten egyszerre ugyanannak a szemafornak az erteket megvaltoztatni ugy, hogy a valtoztatas a rendszerben
inkonzisztenciat okozna. (Inkonzisztencia peldaul onnan eredhetne, hogy ha ket folyamat
egyszerre probalja egy 2 byteos szemafor erteket megvaltoztatni, es ekozben az egyiknek
kiosztott id}szelet lejar miutan a ket byte egyiket atall totta (de a masik byteot meg
o
nem), a vezerlest megkapja a masik folyamat, az atall tja a szemafor erteket a maga
elkepzelesei szerint, majd amikor a vezerlest visszakapja az el}z} folyamat, akkor az
oo
atall tja a masik byteot, es ezzel kaotikus allapotok alakulhatnak ki).
Az osztott memoria hasznalata lehet}ve teszi azt, hogy egy bizonyos memoriateruletet
o
(nyilvan a benne tarolt adatokkal egyutt) egyszerre tobb folyamat is lassa.
Az uzenetek lehet}ve teszik egy-egy memoriaterulet (bu er) tartalmanak
o
atkuldeset az egyik folyamattol a masiknak. Ket primit v m}velet van az uzenetek
u
kezelesere: uzenet elkuldese es uzenet fogadasa. Az uzenetfogado primit v lehet blokkolo
vagy nem-blokkolo aszerint, hogy ha a vegrehajtasanak pillanataban meg nem erkezett
a folyamat szamara uzenet, akkor a program varjon egy uzenet beerkezeseig vagy fusson
tovabb jelezve azt, hogy nem volt beolvashato uzenet.

2.4 A UNIX fajlrendszere
A UNIX operacios rendszer fajlrendszere hierarchikus, a rendszerben egyetlen gyokerdirectory van, es annak tetsz}leges melysegben tetsz}leges szamu aldirectoryja lehet,
o
o
azoknak az aldirectoryjainak szinten tetsz}legesen sok aldirectoryjuk lehet, stb. A UNIX
o
a fajlt egyszer}en egy byte-folyamnak tekinti. A UNIX rendszerben letezik a munkau
directory koncepcioja (minden folyamatnak van egy sajat munka-directoryja). A UNIX
abban lenyegesen kulonbozik az MS-DOS-tol, hogy csak egy gyoker-directoryja van, es a
magneslemezeken lev} kulon fajlrendszerek (a lemezen kialak tott directory-strukturak)
o
beilleszthet}k (mountolhatok) a gyokerdirectory- rendszerbe. Erre nezzunk egy peldat {
o
a UNIX gyoker-fajlrendszere tartalmaz tobb directoryt:
fajlnev
/etc
/etc/passwd
/etc/limit
/usr
/usr/csb
/lib
/tmp
/bin

szerepe
egy aldirectory a rendszerfajloknak
a jelszofajl a /etc directoryban (ez FILE!)
egy aldirectory a /etc directoryban
a felhasznalok directoryjait tartalmazo directory
a "csb" nev} felhasznalo fajljait tartalmazo directory
u
a UNIX C konyvtarait tartalmazo directory
temporalis fajlokat tartalmazo directory
Fontosabb rendszerprogramokat tartalmazo directory.

Most tegyuk fel, hogy van egy fajlrendszerunk egy oppy-diszken, amely a kovetkez}
o
dolgokat tartalmazza:

2.4. A UNIX FAJLRENDSZERE
fajlnev
/alma
/mylib
/mylib/alma
/barack
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szerepe
valamilyen fajl
a fajlrendszeren egy "mylib" nev} directory
u
a mylib directoryn belul az alma nev} fajl
u
egy tetsz}leges barack nev} fajl
o
u

A felhasznalo kerheti a UNIX rendszert, hogy illessze be a oppy-diszken lev}
o
fajlrendszert a gyoker-fajlrendszer valamelyik ures directoryjaba. Most nezzuk, hogy
mi lesz akkor, ha a fenti gyoker-fajlrendszer /usr/csb directoryjaba beillesztjuk a fent
elkepzelt oppy-diszken lev} fajlrendszert. Ezutan a oppyn lev} fajlokat a kovetkez}
o
o
o
neveken erhetjuk el:
/usr/csb/alma
/usr/csb/mylib
/usr/csb/mylib/alma
/usr/csb/barack

(a
(a
(a
(a

oppyn a /alma nev} fajl)
u
oppyn a /mylib directory)
oppyn a /mylib/alma fajl)
oppyn a /barack nev} fajl)
u

Termeszetesen ha ezekre a fajlokra mashol lenne szukseg (pl. a /tmp directoryban, akkor oda is be lehetne oket illeszteni - mountolni). Ez az alapja a UNIX un.
}
keszulekfuggetlensegenek. A fajlokra valo hivatkozaskor nem kell tudni azt, hogy az
adott fajl milyen zikai periferian van. Ehelyett eleg a fajlnak a fajlrendszer-hierarchiabeli
nevet megadni.
A UNIX-ban minden egyes fahlhoz tartoznak un. vedelmi bitek (ezeket rwx
biteknek is nevezik). A fajlokat ezekkel lehet vedeni a jogosulatlan hozzaferes ellen.
Mint mar szo volt rola, minden felhasznalonak van egy sajat uid-je, gid-je. Lenyegeben
ez a UNIX fajlvedelmenek az alapja. Minden egyes fajlhoz tarolva van az }t letrehozo
o
felhasznalo uid-je es gid-je, illetve a fent eml tett rwx- bitek (osszesen 9 bit). Az rwx-b}l
o
az "r" bet} a fajl elolvasasi jogat jelenti, a "w" bet} a fajl felul rasi (modos tasi) jogat
u
u
jeloli, es a vegrehajthato programok eseten az "x" bit a vegrehajtasi jogot jeloli. Az
rwx-bitekkel meg lehet adni, hogy a fenti 3 jog kozul a fajlt letrehozo felhasznalonak
milyen jogai vannak a fajlon a fajlt letrehozo felhasznalo csoporttarsainak milyen jogai
vannak es vegul meg lehet adni, hogy azoknak az "egyeb" felhasznaloknak, akik a fenti
ket halmaz egyikebe sincsenek benn mik legyenek a jogai. (A vedelmi bitek sorrendje
ugyanez el}szor a tulajdonos, majd a csoporttarsak, vegul pedig az egyeb felhasznalok
o
jogait kell megadni.) Ha egy fajl vedelmi bitjei r-xr-x--x alakuak, akkor a tulajdonos a
fajlt elolvashatja, vegrehajthatja (de nem modos thatja) a tulajdonos csoporttarsainak
ugyanez a joguk az egyeb felhasznaloknak pedig csak vegrehajtasi joguk van. A fajlhoz
tartozo vedelmi biteket csak a fajl tulajdonosa vagy a root (superuser) valtoztathatja
meg.
Ezen k vul nehany vegrehajthato fajlnal erdemes hasznalni a UNIX egy mas specialis
lehet}seget: a sticky bitet. Ha ez a bit be van all tva egy vegrehajthato fajlon, es a fajlban
o
tarolt programot vegrehajtjak, akkor a program befejez}dese utan a kodszegmense (ha
o
az nem valtozott meg) megmarad a winchester virtualis memoria teruleten - gy egy
kovetkez} vegrehajtas valosz n}leg gyorsabban fog elkezd}dni, mivel a kodszegmens
o
u
o
ujboli betoltese megsporolhato. (Egy specialis vedelmi bitr}l - a setuid bitr}l kes}bb
o
o o
lesz szo.)
A UNIX rendszerben egy masik nagyon jo otlet az un. specialis fajlok koncepcioja.
Ilyen modon az egyes hardware periferiakat a fajlrendszerbeli nevukon erhetjuk el. Az
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otlet azon alapszik, hogy peldaul egy 360 KByte-os (mondjuk IBM PC/XT formatumu)
oppy-diszket tekinthetunk ugy, mint egy 360 KByte-os fajlt. Ha a lemezen a blokkmeret
512 byte, akkor az ilyen fajl els} karaktere a diszk 0-adik blokkjaban az els} byte a fajl
o
o
512-edik karaktere a diszk 0-adik blokkjaban az utolso (512-edik) byte, peldaul az 1025odik byte pedig a diszk masodik blokkjanak az els} karaktere Vannak blokk-specialis
o
fajlok, es karakter-specialis fajlok. A blokk-specialis fajlok abban kulonboznek a karakterspecialis fajloktol, hogy a blokk-specialis fajloknak nehany "gyakrabban hasznalt" blokkja
a cache memoriaban marad a gyorsabb eleres erdekeben, m g a karakter- specialis
fajloknal erre nincs lehet}seg.
o
A UNIX fajlrendszreben a /dev directory tartalmazza az ilyen specialis fajlokat.
Peldaul a legtobb rendszerben a /dev/fd0 neven a 0-as lemezegyseget erhetjuk el (PCken ez az MS-DOS alatt az A: jel} lemezegyseg).
u
A UNIX masik erdekes lehet}sege a pipe ( cs}vonal). Ez a parhuzamos folyamao
o
tok kozotti kommunikacio (IPC) egyik eszkoze. Ezt tenyleg ugy tekinthetjuk, mint ket
folyamat kozti cs}vonalat: az egyik folyamat rhat ebbe a cs}vonalba valamilyen adao
o
tokat, a masik folyamat pedig kiolvashatja a be rt adatokat a pipe-bol. (A pipe csak
egy half-duplex (egyiranyu) kapcsolatot biztos t, vagyis ha mindket resztvev} folyamat
o
akar a masiknak adatokat kuldeni, akkor a ketiranyu adatatvitelhez ket ilyen pipe-ra van
szukseg.) A pipe-ra rni es arrol olvasni is a UNIX fajlm}veleteivel lehet. S}t lehet}seg
u
o
o
van arra is, hogy pipeokat nevvel lassunk el (a pipeok nevei ekkor fajlnevek lesznek,
amin keresztul barmelyik folyamat tud a pipera rni - esetleg arrol olvasni, ehhez csak a
pipehoz tartozo fajl nevet kell ismernie).
Erdekes meg, hogy a halozati kapcsolatok is lenyegeben fajldeszkriptorokon keresztul
erhet}k el, de err}l majd kes}bb lesz szo.
o
o
o
A UNIX egy tobbfelhasznalos operacios rendszer, gy egy fajlt egyszerre tobb felhasznalo is valtoztathat. Ez gyakran problemak forrasa is lehet. Nezzuk a kovetkez}
o
helyzetet: egy bank szam togepen UNIX rendszer fut, a szam togephez tobb keperny}
o
van kapcsolva (minden egyes penztaros asztalan van egy-egy terminal). Tegyuk fel, hogy
ket penztarhoz egyszerre megy oda ket ugyfel, es ugyanarra a bankszamlara mindketten 500 forintot akarnak rakni. Ekkor mindket szam togep kiolvassa a szamla aktualis
egyenleget (ez legyen mondjuk 1000 forint), kiszamolja, hogy mennyi lesz az 500 forint
berakasa utan az uj egyenleg (1500 forint), es vissza rja azt. Mivel ezek az ugyfelek lehet,
hogy nem is tudnak arrol, hogy a masik is ugyanarra a szamlara rakott be 500 forintot,
boldogan mennek hazafele a bank-igazolassal, amelyen uj egyenlegkent 1500 forint van
feltuntetve, nem veszik eszre, hogy a gep hibazott. Mivel a gyakorlatban az ilyen eseteket
nem szabad elhanyagolni (egy nagyobb bank kozponti szam togepere tobb ezer terminalt
ra lehet kapcsolni), es sok olyan szamlaszam van, amelyre sokan zetnek be penzt (pl.
kozhasznu alap tvanyokra), ezert erre kell valami megoldast talalni.
A UNIX az ilyen esetekre nyujtja a fajl- ill. rekord-lefoglalas (fajl and record
locking) lehet}seget. Egy folyamat kerheti az operacios rendszert, hogy egy fajlt vagy
o
annak egy reszet "foglaljon le" egeszen addig, am g a folyamat el nem vegzi rajta a dolgat
(mondjuk inkabb ugy, hogy a feladatat ). A lefoglalas ideje alatt mas folyamat nem
nyulhat a fajl lefoglalt reszehez ha megis hozza akarna nyulni, akkor varnia kell addig,
am g a fajlt lefoglalo folyamat "elengedi" a fajlt.
Masik fontos elteres a UNIX es az MS-DOS fajlrendszere kozott az, hogy a UNIX
fajlrendszerben nem egy kozos nagy MS-DOS-ban hasznalt FAT-szer} tablazatban
u
taroljak azt, hogy a fajl a diszk melyik blokkjain helyezkedik el, hanem minden egyes
:::

:::
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fajlhoz kulon taroljak (egy-egy a fajlhoz tartozo un. i-nodeban) azt, hogy a fajl a diszk
melyik reszen helyezkedik el. Az i-node tarolja azt is, hogy ki a fajl tulajdonosa (mi volt
a tulajdonos uid-je es gid-je akkor amikor a fajlt letrehozta), mekkora a fajl hossza (byteban merve), mikor hoztak letre, mikor modos tottak utoljara, mik a fajl vedelmi bitjei.
Minden egyes i-nodenak van egy sorszama, es a directoryk (lenyegeben specialis fajlkent
- amit megnyithatunk es ezeket az informaciokat kiolvashatjuk bel}le) a kovetkez} ino
o
formaciok sorozatat tartalmazzak:
maximum 14 karakteres fajlnev hozza tartozo i-node sorszama
Ez azert hasznos, mert gy egy fajlra tobb directorybol is hivatkozhatunk. Ezzel
megoldhatjuk azt, hogy ket vagy tobb felhasznalo ugyanazt a fajlt elerje a sajat directoryjabol. Erre nezzuk a kovetkez} peldat: a /usr/pista directoryban van egy ilyen
o
bejegyzes :
test.c 234
a /usr/mariska directoryban pedig a kovetkez} bejegyzes van (a szerkezet a fent
o
bemutatottak szerint ertend}):
o
proba.c 234
Itt a test.c illetve a proba.c fajloknak mas a neve, de a ket fajl (tartalma) egy
es ugyanaz. Ha mondjuk a /usr/mariska/proba.c fajl le lesz torolve, akkor a fajl
(a benne tarolt adatokkal) a lemezr}l nem lesz letorolve, mert meg hivatkoznak ra
o
/usr/pista/test.c neven. (Egy ilyen hivatkozast neveznek az i-nodera mutato linknek
- nyilvan az i-node tartalmaz egy referenciaszamlalot, es a fajl csak akkor lesz tenylegesen
torolve, ha e referenciaszamlalo erteke nullara csokken.) Eszerint egy fajl a lemezr}l csak
o
akkor lesz letorolve, ha ra egyetlen link sem vonatkozik.
Itt erdemes megjegyezni azt is, hogy az i-node tartalmazza azokat az informaciokat,
amely alapjan a fajl helye a diszken "felterkepezhet}" a kovetkez}k szerint . Az i-node
o
o
tartalmaz 13 darab blokk-c met (a UNIX csak blokk-eleres} periferiakon tud fajlrendszert
u
letrehozni) - most a pelda konnyebb megertese erdekeben feltetelezzuk, hogy a blokkmeret
1 KByte. Ebb}l a 13 blokk-c mb}l 10 darab un. direkt c m. Azaz azok kozul az els}
o
o
o
tartalmazza annak a (diszk-)blokknak a c met, amelyen a fajl els} 1024 (1 Kbyte) darab
o
byteja van. A masodik tartalmazza annak a (diszk-)blokknak a c met, amelyen a fajl
kovetkez} 1024 byteja van, stb. . A 11-edik blokk-c m egy un. egyszeres indio
rekt blokk-c m (single indirect): az a blokk, amelyet ez az egyszeres indirekt blokkc m megc mez mind direkt c meket tartalmaz. (Ha egy blokk-c m merete n byte, akkor
osszesen 1024/n darab direkt c m fer ide.) Vagyis az egyszeres indirekt blokkban tarolt
els} c m a fajl 11-edik kilobytejat tartalmazo diszk-blokk c met tartalmazza.
o
A 13-bol a 12-edik egy un. ketszeres indirekt blokk-c m (double indirect address):
az a blokk, amelyet ez a ketszeres indirekt blokk-c m megc mez mind egyszeres indirekt
c meket tartalmaz - ezek szerkezete olyan, mint azt az el}bb le rtam.
o
A 13-adik pedig egy haromszoros indirekt blokk-c m (triple indirect): az ez altal
megc mzett blokk 1024/n darab ketszeres indirekt blokk- c met tartalmaz. (Ha egy
fajl hossza mondjuk 4567 byte, akkor csak az els} 5 direkt c m van kitoltve "ertekes"
o
informaciokkal. A tobbi helyen mindegy mi van.)
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2.5 A UNIX shelljei
A UNIX-ban (az MS-DOS-hoz hasonloan) tobbfajta shell lehet, es minden egyes felhasznalo a rendelkezesre allo shellek kozul valaszthat egyet maganak, amit majd
hasznalni fog. Jelenleg a legelterjedtebb shellek a kovetkez}k: Bourne-shell (ez mino
den UNIX rendszerben megtalalhato) C-shell (ezt a shell mar kevesebben hasznaljak) a
Korn-shell pedig a legujabb shell, ami a Bourne-shell kiterjesztesenek tekinthet} (azzal
o
kompatibilis).
A UNIX shelljei programozhatok (mint peldaul a nagy IBM gepek shellje, a REXX),
a shell "programnyelve" a leginkabb a C nyelvhez hasonl t. Hatekonysagat mutatja, hogy
adatbaziskezel} rendszereket is rtak mar benne (ehhez egyeb "szabvanyos" utilityket is
o
felhasznalva, mint peldaul az awk - a shell onmagaban nem volt ehhez eleg).

2.6 Vedelem a UNIX operacios rendszerben
A UNIX rendszer vedelmi rendszere eleg jo. A rendszerbe bejelentkezni minden felhasznalo csak a jelszavaval tud. A UNIX megvedi az egyik felhasznalo futo programjait
egy masik felhasznalo illegalis beavatkozasa el}l (vagyis nem tudom a tanar programjat
o
"kil}ni"). Masreszt pedig lehet}seg a fajlok vedelmere a jogosulatlan hozzaferesek el}l.
o
o
o
A UNIX vedelmi koncepciojahoz hozzatartozik az is, hogy van egy un. szuperfelhasznalo
(legtobbszor } a "rendszergazda" - a root), aki majdnem minden vedelmi korlatot
o
megserthet, mindenkinek a fajljaihoz hozzaferhet. (Erre szukseg is van, kulonben nem
tudna a rendszerben lev} fajlokrol biztonsagi masolatokat kesz teni. Ha nem keszulnenek
o
biztonsagi masolatok, akkor egy rendszerhiba eseten lehet, hogy egyes felhasznaloknak
nagyon sok ertekes munkaja veszne el.) (Most mar erthet}, hogy miert probaljak meg
o
peldaul az egyetemeken a hallgatok a szuperfelhasznalo jelszavat kitalalni.)
A UNIX ellen}rizhet} modon lehet}seget ad arra, hogy egy felhasznalo valamely mas
o
o
o
felhasznalo jogaival rendelkez} folyamatot elind tson. Ennek eszkoze a setuid bit. Ez
o
azt jelenti, hogy ha egy vegrehajthato program el van latva a setuid bittel, akkor a program vegrehajtasa alatt nem a sajat uid-unknek megfelel} jogaink vannak, hanem annak
o
a felhasznalonak a jogaival rendelkezunk, akie a program (az lesz a folyamat e ektiv
user-id-je). Ezzel nagyon ovatosan kell banni! Kulonosen veszelyesek lehet az, ha egy
program un. setuid root program, vagyis ha valaki ezt a programot vegrehajtja, akkor a
vegrehajtas ideje alatt a szuperfelhasznalo jogaival rendelkezik. Ilyen setuid root program
peldaul a passwd, amellyel barmelyik felhasznalo megvaltoztathatja a sajat jelszavat. A
programnak a szuperfelhasznaloi jogok azert kellenek, hogy a jelszofajlt (/etc/passwd)
meg tudja valtoztatni. A setuid bites programokat a kovetkez}keppen lehet felismerni:
o
az ls -l parancs altal kiadott directory-listaban a program tulajdonosara vonatkozo rwx
bitek x bet}je helyen egy s bet} all (pl. rws--x--x). Kes}bb meg lesz szo rola, hogy
u
u
o
milyen eszkozokkel lehet viszonylag "biztonsagos" setuid root programokat rni.
Az IPC eszkozokhoz is tarolva van a letrehozo folyamat felhaszaloi azonos toja es
csoport-azonos toja (uid ill. gid), illetve tarolva vannak hozza a szokasos rwx-bitek is.
Ez teszi biztonsagossa a folyamatok kozotti kommunikaciot.
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2.7 A UNIX INPUT/OUTPUT rendszere
A UNIX a hardver berendezesekkel a device driverek seg tsegevel kommunikal (ott van
"elrejtve" az operacios rendszer gepfugg}, hardver-fugg} resze). A device driverek nem
o
o
illeszthet}k be olyan dinamikusan egy hagyomanyos UNIX rendszerbe, mint ahogyan
o
az az MS-DOS alatt megy (a CONFIG.SYS fajlon keresztul), es a device driverek nem
olyan felep tes}ek, mint mondjuk a DOS megfelel}ik (egy UNIX device drivernek mas
u
o
szolgaltatasokat kell nyujtania, mint egy DOS device drivernek). Azt erdemes tudni, hogy
egyik PC-s UNIX sem hasznalja a BIOS-t, mert a BIOS rutinok ugy vannak meg rva,
hogy varnak az I/O m}velet befejez}deseig, es csak ezutan adjak vissza a vezerlest az
u
o
operacios rendszernek, ami egy multiprogramozott operacios rendszerben elfogadhatatlan.
A device drivereket a UNIX kernel tobbi reszevel ossze kell linkelni (itt most a
linkage editorra gondoljunk, ne a fajlrendszer linkjeire). A device driverek bizonyos
szolgaltatasokat nyujtanak a kernelnek (pl. minden device drivernek lehet egy olyan rutinja, amelyet a ra vonatkozo open()-nel kell megh vni ). Ezek a rutinok egy az egesz
kernelre nezve globalis tombben vannak felsorolva. Egy device driver szolgaltatasainek
ezen tombbeli indexet nevezik a devicehoz tartozo major device numbernek. (Lenyegeben
ezen keresztul lehet a device drivereket egymastol megkulonboztetni.)
Minden device driver kezelhet tobb (egymastol akar fuggetlen akar nem fuggetlen)
periferiat is, amiket az un. minor device numberekkel kulonboztethet meg egymastol.
(Egy specialis fajlhoz tartozo az i-nodeban a 13 blokk- c m helyen van tobbek kozt
a minor ill. major device number tarolva.) Amikor egy specialis fajlt megnyitunk a
fajlrendszerben tarolt neve alapjan, akkor az operacios rendszer az i-node alapjan tudja,
hogy az egy specialis fajl, megszerzi az i-nodebol a major ill. minor device numbereket, es
a device driver open() szolgaltatasat vegz} rutint megh vja (tobbek kozt a minor device
o
numberrel mint parameterrel).
A device driverek lenyegeben harom csoportba sorolhatoak: a karakteres interface-t
nyujtoak, a blokk-interfacet nyujtoak es a STREAMS driverek.
:::

2.7.1 A UNIX architekturajanak modernizalasa
A UNIX operacios rendszer egy monolitikus rendszer: van ugyan jo nehany logikailag
egymastol elkulon thet} komponense, de a jelenlegi strukturaban meg akadnak problemak
o
az uj hardware-re torten} at raskor. A Carnegie Mellon egyetemen az utobbi evekben
o
leginkabb azzal foglalkoztak, hogy hogyan lehetne a UNIX-ot (}k a k serletezeseikre a
o
Berkeley UNIX 4.3BSD valtozatat hasznaltak) gepfugg} illetve gepfuggetlen reszekre
o
bontani. E munka eredmenyekent jott letre a Mach mikrokernel, amely a modos tott
Berkeley UNIX "gepfugg}" reszeib}l lett kifejlesztve. A Mach-ot is egy operacios rendo
o
szerre alak tottak: a UNIX "gepfuggetlen" reszet ugy rtak at, hogy az a Mach operacios
rendszer szolgaltatasait hasznalja ki ott, ahol valamilyen gepfugg} szolgaltatast kell
o
elvegeznie. Az gy elkeszult rendszer teljesen kompatibilis az eredeti Berkeley UNIXszal ( gy binaris kompatibilitast is el tudtak erni, vagyis a regebbi 4.3BSD-n meg rt programokat ujra se kell ford tani ahhoz, hogy az uj Mach-alapu rendszereken hasznaljuk
o
}ket).
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A Mach mikrokernel szerkezete
Ez a resz roviden vazolja a Mach 3 kernel felhasznaloi szamara nyujtott feluletet.
A Mach rendszert operacios rendszerek alapjanak terveztek.
Szeleskor}
u
lehet}segekkel rendelkezik a memoriakezeles teren, biztos tja a folyamatonkent (Mach
o
terminologiaban taszkonkent) tobb vegrehajtasi pont letrehozasanak lehet}seget (angol
o
neven threadek alkalmazasat) es jo folyamatok (taszkok) kozti kommunikacios eszkozoket
nyujt. A Mach alapvet} jellemz}i a kovetkez}k:
o
o
o
Rugalmas memoriakezelesi technikak biztos tasa a futo folyamatoknak.
Transzparens hozzaferesi lehet}seg biztos tasa a halozaton keresztul elerhet}
o
o
er}forrasokhoz, ehhez a megfelel} kommunikacios modszerek biztos tasa.
o
o
A korabbi szoftver-kornyezetekkel valo kompatibilitas biztos tasa (peldaul a Berkeley UNIX rendszerrel).
Lehet}seget kell teremteni minel magasabbfoku parhuzamos tasra mind az
o
operacios rendszerben mind pedig az alkalmazoi programokban.
A 2.5-os es korabbi valtozataiban a Mach rendszert beagyaztak a Berkeley UNIX-ba
es gy biztos tottak a "hagyomanyos" (UNIX-szer}) operacios rendszer szolgaltatasok jo
u
reszet. A 3.0-as valtozattol kezdve a Mach mar csak alapvet} kernel szolgaltatasokat
o
nyujt, nem biztos tja a kernelbe agyazva a korabbi valtozatokban megismert szeleskor}
u
operacios rendszer szolgaltatasokat (mint peldaul a fajlkezelesi operacios rendszer
szolgaltatasokat). Itt az operacios rendszer funkcionalitast nem a kernelbe agyazva,
hanem un. kernelen k vul futo szerverekkel biztos tjak.
Termeszetesen a taszkok kommunikaciojan k vul vannak mas szolgaltatasok is, amiket
a kernelnek kell biztos tania { ilyenek peldaul a kovetkez}k:
o
A taszkok es vegrehajtasi pontjaik (threadek) kezelese.
A taszkok virtualis memoriajanak biztos tasa es kezelese.
Hardware periferiak kezelese (peldaul a processzorok, periferiak es az ora),
valamint egy magasabbszint} hardware-interfesz biztos tasa az operacios rendszer
u
szolgaltatasokat biztos to taszkok fele.
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A Mach kernel absztrakcioi: Bar a Mach kernel tervezesekor cel volt a kernel

altal biztos tott absztrakcios eszkozok szamanak csokkentese, nem volt cel az ezen
eszkozok altal biztos tott lehet}segek sz}ken tartasa. A legfontosabb kernel absztrakciok
o
u
a kovetkez}k:
o
taszk { Er}forrasok lefoglalasara kepes egyseg (minden taszknak van egy
o
sajat memoriac mtartomanya, es minden taszkhoz tarolva vannak a taszk porthozzaferesi jogosultsagai is).
thread { Programvegrehajtasi pont (kicsi az er}forrasigenye).
o
port
{
Kommunikacios csatorna, hozzaferes csak megfelel} adatkuldesi/adatfogadasi joo
gon keresztul lehetseges.
uzenet { Adatobjektumok gy}jtemenye.
u
memoria objektum { A memoriakezeles bels} egysege (ezeken keresztul
o
vezerelhetik az egyes taszkok a memoriakezelest).

Taszkok es threadek: Mivel minden operacios rendszer nyilvantart bizonyos informaciokat a folyamatokrol, mint peldaul a futtato felhasznalo azonos tojat, signalkezelH
ok1 allapotat, es ez a folyamat absztrakcio operacios rendszerenkent mas es mas, ezert a
Mach kernel (a 3.0-as valtozattol kezdve) nem biztos tja a mas operacios rendszerekben
megtalalhato folyamat fogalmat, a Mach folyamat fogalma sokkal primit vebb.
Egy taszk osszes threadje hozzafer a taszk osszes er}forrasahoz. Ket taszknak
o
alapertelmezes szerint nincsenek kozos er}forrasaik (bar lehetnek kozos er}forrasaik,
o
o
ehhez azonban a taszkoknak gondoskodniuk kell arrol, hogy a kozos hozzaferes}
u
er}forrasok mindkett}jukben elerhet}k legyenek { ehhez a Mach kernel biztos t nem tul
o
o
o
bonyolultan hasznalhato mechanizmusokat).
Egy thread kis raford tassal letrehozhato, m}kodesehez keves er}forrasra van szuksege
u
o
(ez azert van gy, mert a threadhez tartozo bels} allapot minimalis { altalaban a proo
cesszor regiszterkeszlete { es az altala elert er}forrasok kezeleset az ot tartalmazo taszk
o
}
vegzi). Egy multiprocesszoros rendszerben egy taszknak egyidej}leg tobb threadje is
u
vegrehajtodhat.

A Mach memoriakezelese: A Mach kernel biztos tja a nagy, nem feltetlenul

osszefugg} memoria kezelesehez szukseges mechanizmusokat. Minden taszk rendelkezik
o
egy kernel altal manipulalt c mterkeppel, amely vezerli a virtualis memoriac mek zikai
memoriac mekre torten} lekepezeset. Mint az a virtualis memoriat biztos to rendszerek
o
nagy reszere jellemz}, a taszkok virtualis c mtartomanyanak mindig van egy-egy resze,
o
amely nincs benn a zikai memoriaban egy-egy adott id}pillanatban, ezert kell valamilyen
o
mechanizmus a zikai memorianak a taszkok virtualis c mtartomanyanak a cache-elesere
valo hasznalatara (es valosz n}leg ez a Mach-ban megjelen} egyik legnagyobb otlet).
u
o
Nem ugy, mint mas virtualis memoriat kezel} rendszerek, a Mach kernel nem impleo
mentalja ennek a cache-elesnek az osszes reszletet, ehelyett lehet}seget nyujt felhasznalo
o
altal kesz tett taszkoknak arra, hogy e cache-eles egyes reszleteit megvalos tsak.
1

Kiveteles esemenyek kezeleseert felel}s eljarasok.
o
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Egy taszk allokalhat uj memoriateruleteket, deallokalhat memoriateruleteket es
modos thatja a rajuk vonatkozo vedelmi informaciokat. Ezenk vul egy taszk
meghatarozhatja az egyes memoriareszeinek az oroklesi jellemz}it is. Egy uj
o
taszk letrehozasakor mindig ki kell jelolni egy mar meglev} taszkot, amelyet az uj
o
taszk memoriaszerkezetenek kialak tasakor az operacios rendszer mintanak fog tekinteni. Ilyenkor a meglev} (mintakent hasznalando) taszkban lev} egyes memoriareszek
o
o
oroklesi jellemz}i hatarozzak meg azt, hogy az ujonnan letrehozott taszkban a megfelel}
o
o
memoriaresz de nialt legyen-e, illetve amennyiben azt a reszt az uj taszk orokli, akkor a
szul}taszkkal egy kozos, megosztott memoriateruletkent hasznalja azt, vagy pedig sajat
o
peldanyt kell, hogy kapjon.
A Mach rendszerben a legtobb memoriamasolasi m}velet copy-on-write modszerrel
u
van optimalizalva: a masolando memoriareszek tartalma nem lesz egyb}l lemasolva,
o
hanem masolas utan a haznalok a ket peldanyt " rasvedetten" ugyan, de kozosen
hasznaljak tovabb. Ha barmelyik hasznalo megprobalja a kozosen hasznalt " rasvedett"
memoriaresz tartalmat modos tani, akkor a megfelel} resz tenyleges lemasolasara
o
a modos tas pillanataban kerul sor. Ez a kesleltetett memoriamasolas egy fontos
hatekonysagot novel} optimalizacio a Mach kernelben.
o
Barmely memoriaresz mogott van egy-egy memoria objektum. Egy memoriakezel} taszk biztos tja a ( zikai) memoriaban lev} lapok tartalma es az ugyanehhez
o
o
az informaciotartalomhoz tartozo, nem a zikai memoriaban tarolt informacio (egy absztrakt memoria objektum) kozti kapcsolatot, konverziot. A Mach kernel tartalmaz
egy alapertelmezeskent hasznalhato memoria-kezel}t, amely olyan memoria objektumok
o
letrehozasat biztos tja, amelyek kezdetben nulla kodu ertekekkel vannak feltoltve, es a
rendszer lapozasi teruletere lesznek szukseg eseten kilapozva.

Taszkok kozti kommunikacio: A taszkok kozotti kommunikacio a Mach

eszkoztaranak egy nagyon fontos elemet alkotja. A Mach egy kliens/szerver alapu
rendszerstrukturat feltetelez, ahol egyes taszkok (kliensekkent) mas taszkok (szerverek)
szolgaltatasait erhetik el a az }ket osszekot} kommunikacios csatornan keresztul kuldott
o
o
uzenetek seg tsegevel. Mivel a Mach kernel onmagaban keves szolgaltatast nyujt (peldaul
a fajlkezelesi szolgaltatas sem resze), ezert egy "atlagos" Mach taszk sok mas taszkkal
kell, hogy kommunikaljon annak erdekeben, hogy hozzaferjen a szamara szukseges
szolgaltatasokhoz. A taszkok kozotti kommunikacio kommunikacios csatornajat portnak
nevezik. Egy port egy egyiranyu csatorna, amelyen lehet koratos mennyiseg} uzenet.
u
Egy uzenet tartalmazhat adatokat, memoriareszeket es portok hozzaferesi jogait. Egy
port hozzaferesi joga egy nev, amellyel az adott taszk a porthoz valo hozzaferesi jogosultsagat azonos tja (a Mach kernellel szemben). Egy taszk csak akkor ferhet hozza egy
porthoz, ha a portra vonatkozoan a megfelel} hozzaferesi jogokkal rendelkezik. Egy adott
o
portra vonatkozoan csak egyetlen taszknak lehet olvasasi joga. Ez az egy taszk jogosult
a portra kuldott uzenetek feldolgozasara (beolvasasara). Egyidej}leg egy adott portra
u
vonatkozoan tobb taszknak is lehet adatkuldesi joga, amivel lehet}seguk van az adott poro
tra uzenetek kuldesere. Ket taszk kommunikaciojakor a kuld} az elkuldend} adatokbol
o
o
felep t egy uzenetet, es egy uzenetkuldesi m}veletet hajt vegre egy olyan porton, amelyre
u
adatkuldesi joggal rendelkezik. Kes}bb az a taszk, amelynek erre a portra vonatkozoan
o
olvasasi joga van, vegrehajt egy uzenetolvasasi m}veletet. Megjegyezzuk, hogy ez az
u
uzenetatvitel egy aszinkron m}velet. Az uzenet atmasolasa altalaban a korabban is
u
eml tett copy-on-write optimalizacios technikaval tortenik.
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UNIX implementacioja a Machon

A UNIX Mach rendszeren valo implementalasa mogotti alapotletet mar lattuk: szet kell
szedni a hagyomanyos UNIX-ot egy gpefuggetlen es egy gepfugg} reszre, es ezutan a
o
gepfuggetlen (kisebb) resz atvitele utan az operacios rendszer tovabbi komponenseinek a
leford tasa mar sokkal egyszer}bb.
u
Az utobbi evekben mar nemcsak a Carnegie Mellon-on dolgoznak ezen a projekten, hanem a vilagon sokfele. Egyre tobb operacios rendszert modos tanak ugy, hogy
a gepfugg} reszeiket Mach szolgaltatasok vegrehajtasara cserelik, gy azoknak a horo
dozhatosaga is megn}. Jelenleg mar a Linux operacios rendszernek is keszul a Macho
feletti valtozata.
A Mach-alapu operacios rendszerek szerkezetuk alapjan ket csoportba sorolhatok: az
egyszerveres es a tobbszerveres implementaciok csoportjara. Az egyszerveres implementaciok (ilyen lesz peldaul a Mach-alapu Linux, es ilyen a mar elkeszult Mach-alapu
4.3BSD) a UNIX "gepfuggetlen" funkcionalitasat egyetlen programban "monolitikusan"
implementalja. Ezzel szemben a tobbszerveres implementaciok (ilyen lesz peldaul a GNU
Hurd operacios rendszere) tobb program (un. szolgaltato program, szerver) seg tsegevel
valos tjak meg a UNIX funkcionalitast: itt peldaul lehet, hogy kulon program foglalkozik
a fajlrendszerrel, kulon program a memoriakezelessel, kulon program vegzi a felhasznalok
igazolasat, a periferiakezelest, stb.

2.8 Kerdesek, feladatok
1. Mi alapjan kulonbozteti meg a UNIX az abszolut es a relat v pathname-eket.
2. Ismertesse a UNIX fajlrendszerenek a bels} szerkezetet!
o
3. Milyen esetben mi a esszer}bb az 512 byteos diszk-blokk valasztas, mint az 1024
u
byteos blokkok? Miert?
4. Milyen informaciok kerulhetnek bele a UNIX rendszer processz-tablajaba?
5. Hogyan valos thato meg az utemez} az Intel 8088 mikroprocesszoron? s az Intel
o
80386-on?
6. Mit jelentenek a kovetkez} fogalmak?
o
id}szelet
o
rwx-bitek
szuperfelhasznalo
specialis fajl
fajl-attributum
i-node
i-node-ra mutato link
setuid bit
single indirect
major device number
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7.

8.
9.
10.

minor device number
Pista (uid=234 gid=17) rt egy levelet, es a kovetkez} ertekekre all totta a levelet
o
tartalmazo fajl vedelmi bitjeit: rwxr|{. (A - jel azt jelenti, hogy az ott lev} jog
o
nincs megadva.) El tudja-e ezt a levelet olvasni Mariska (uid=252 gid=17)? s
Zsolt (uid=756 gid=50) el tudja olvasni?
Mi a pipe?
Sok programozo osztott memoria hasznalataval szimulalja az uzenetatadast, mivel
az gyorsabb megoldasnak t}nik. Tenyleg gyorsabb? Vagy nem feltetlenul?
u
A hierarchikus directoryszerkezetet abrazolni lehet egy a gyoker-directorybol kiindulo fastrukturaval. Mi a helyzet, ha bejonnek a UNIX-ban megismert LINK-ek?
Ekkor milyen gra al lehetne hasonlo modon jellemezni a fajlrendszert?

Fejezet 3
Rendszerh vasok
Az operacios rendszerek a felhasznaloi programok el}l eltakarjak a gephez kapcsolt
o
"nyers" hardver reszleteket, es a programozonak gy kenyelmes programfejlesztesi
kornyezetet biztos tanak. S}t a legtobb komoly rendszerben az operacios rendszer nem
o
is engedi meg, hogy az "atlagos" felhasznalok beleturkaljanak a rendszer lelkivilagaba
(peldaul a UNIX rendszerben sincs mindenkinek megengedve az, hogy a oppy-diszkhez
tartozo specialis fajlt megnyissa es hasznalja). Ehelyett az operacios rendszer un.
szolgaltatasokat nyujt a programoknak. Ilyen szolgaltatas peldaul egy adott nev} fajl
u
megnyitasa, egy adott fajlbol karakterek olvasasa, illetve fajlba karakterek rasa, stb ...
Ezeket a szolgaltatasokat a programok (a szolgaltatasok (ki)hasznaloi) un. rendszerh vasokon keresztul erhetik el. Ezt ugy kell erteni, hogy minden felhasznaloi program a
processzor felhasznaloi uzemmodjabanfut, szamol, ciklust szervez, stb ... Ha valamiolyan
m}veletet akar vegrehajtani, amely esetleg mas futo programokat megzavarna (peldaul
u
ilyenek a fajlm}veletek), akkor meg kell kernie az operacios rendszert, hogy hajtsa vegre
u
neki a kert m}veletet. Az operacios rendszer ellen}rizheti, hogy a felhasznalonak van-e
u
o
joga ahhoz, amit kert, es ha nincs, akkor a rendszerh vast visszautas thatja. Ha pedig a
felhasznalonak jogosultsaga van az adott m}velet vegrehajtasara (peldaul egy winchester
u
formattalasara), akkor az operacios rendszer a kert szolgaltatast elvegzi. Ilyen modon
tudja az operacios rendszer az els} fejezetben eml tett feladatat, a hardver er}forrasok
o
o
vedelmet es elosztasat helyesen ellatni.
A kovetkez}kben egy m}kod} operacios rendszer (a UNIX) rendszerh vasain keresztul
o
u o
lesz bemutatva az, hogy milyen eszkozok allnak a programozo rendelkezesere. A UNIX
rendszerh vasainak csak egy nagyon sz}k reszhalmaza lesz bemutatva - f}leg azok, ameu
o
lyek "kozosek" minden UNIX-ban (a 7-es valtozattol kezdve). A rendszerh vasok itt is a
mar korabban eml tett szempontok szerint lesznek csoportos tva.
A rendszerh vasokrol meg annyit erdemes megjegyezni, hogy egy egesz t pusu ertek
a visszateresi ertekuk, es a negat v visszateresi ertek legtobbszor a rendszerh vas
vegrehajtasa alatt fellep} hibat jelzi, vagy azt, hogy a rendszerh vas hiba nelkul leo
futott. Hiba eseten az errno egesz t pusu globalis valtozo tarolja a hiba okat: minden egyes hibafajtat egy-egy egesz szam azonos t, es az errno valtozoban az eppen
vegrehajtott rendszerh vas sikertelenseget okozo hiba kodja van. Ezt a hibakodot ki rni
(a hozza tartozo szokasos angol nyelv} szovegekkel) a perror konyvtari rutinnal lehet
u
(ez nem rendszerh vas!). (Az errno-beli hibakodok egy errno.h include fajlban vannak
"olvashato" formaban: ugyanis ott vannak C nyelv} makrode n ciokkal a hibakodoknak
u
megfelel} "standard" konstansok megadva. Ez egyebkent is jellemz} a UNIX-ra es mas
o
o
37
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rendszerekre is, hogy bizonyos konstansoknak szimbolikus megfelel}it belerakjak a C
o
konyvtarba vagy header-fajlokba. Ez azert jo, mert a programkod ezek hasznalataval
olvashatobb lesz, es ha esetleg a konstanst megvaltoztatjak (vagyis azt, amit az operacios
rendszer var), akkor minden programban megkeresni es at rni ... az nagyon nagy munka
lenne). Ilyen konstansokat (un. manifest-konstansokat) ebben a le rasban is kulon eml tes
nelkul fogok hasznalni. Az egyes rendszerh vasokhoz tartozo referencia kezikonyv lapok
(amit a UNIX man parancs ki r) tartalmazzak azokat a header-fajlokat, amelyek az ott
hasznalhato manifest-konstansokat (... makrokat) de nialjak.

3.1 Folyamatokat kezel} rendszerh vasok
o
A folyamatokat kezel} rendszerh vasok a kovetkez}k: fork(), exec(), exit(), wait(),
o
o
,
,
es nice(). A fork() rendszerh vassal lehet egy uj
folyamatot letrehozni. A letrehozott gyermek-folyamat a szul}-folyamat pontos masolata
o
lesz, vagyis a gyermek-folyamat a szul}-folyamat majdnem minden jellemz}jet orokli (a
o
o
pid-et peldaul nem!). A gyermek- es a szul}-folyamat egymassal parhuzamosan fognak
o
futni. A fork() rendszerh vas C nyelvben egy int t pusu ertekkel ter vissza, es ez az, ami
alapjan meg lehet kulonboztetni, hogy melyik a szul}- ill. melyik a gyermek-folyamat.
o
A gyermek-folyamatban a visszateresi ertek: 0, m g a szul}-folyamatban a visszateresi
o
ertek egyenl} a gyermek-folyamat pid-jevel. Negat v visszateresi ertek a rendszerh vas
o
sikertelenseget jelzi (a hiba oka lehet peldaul az, hogy nem volt eleg memoria a gyermekfolyamat letrehozasahoz). A fork() a kovetkez} formaban fordul el} a leggyakrabban:
o
o
getpid() getppid() setpgrp()

valtozo=fork()
/* Megszuljuk a gyermeket ... */
if (valtozo < 0) {
/* Hibauzenet kiirasa, a sikertelen rendszerhivasrol! */
} else {
if (valtozo == 0) {
...
/* A gyermek ezt csinalja ... */
} else {
...
/* A szulo pedig ezt ... */
}
}

Mi az, amit a gyermek-folyamat fork utan a szul}t}l orokol?
oo
A folyamatot futtato felhasznalora vonatkozo informaciokat (a futtato felhasznalo
azonos tojat, a futtato felhasznalo csoportjanak az azonos tojat)
E ektiv user id-et (ha a program setuid bites, akkor ez elterhet a programot futtato
felhasznalo azonos tojatol)
E ektiv csoport azonos tot
Folyamat-csoport azonos tojat
Munkadirectory
Signal-kezel} eljarasok
o
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umask erteket (ld. kes}bb)
o
Mi az, ami a fork utan elter a szul} es a gyermek kozott?
o
Folyamat-azonos to
Szul} folyamat azonos toja
o
A gyermek folyamatnak sajat masolata van a szul} folyamat fajldeszkriptorjairol
o
Ha a szul} valamikorra egy ALARM signalt kert, azt a gyermek nem fogja
o
megkapni.
A leggyakrabban a gyermek-folyamatnak a szul} feladatatol teljesen elter} dolgot kell
o
o
csinalnia, peldaul egy masik fajlban tarolt programot kell vegrehajtania. Erre valo az
exec rendszerh vas, amely a UNIX kernelnek talan a legbonyolultabb rendszerh vasa.
Az exec tobb kulonboz} formaban erhet} el, itt az execle() h vas lesz bemutatva.
o
o
Amikor egy C nyelv} programot az operacios rendszer shelljeb}l elind tunk, akkor a shellu
o
parancskent beadott programnev utan rt egyeb programparameterek hogyan lesznek a
programbol elerhet}k. A C program f}-eljarasat a kovetkez} modon kell deklaralni:
o
o
o
main(argc, argv, envp)
int argc
char **argv, **envp

A program ezutan a h vaskor megadott parameterek darabszamat az argc
parameteren keresztul tudja megkapni, maguk a parameterek pedig az argv (karakteres tomb) valtozon keresztul erhet}k el. Az envp karakter tomb a shell-valtozokat
o
tartalmazza. Az mindig igaz, hogy argc > 0, es az argv 0] nem ures, mert a nulladik
parancs-parameter az maga a beadott parancsnev szokott lenni. Pelda az execle()
h vasra:
r=execle("/bin/ls","ls","-l","alma.c",(char *)0, envp)

Az els} parameter a vegrehajtando binaris program fajlnevet tartalmazza. A
o
kovetkez} parameter maganak a parancsnak a nevet tartalmazza (ez nem kell, de gy
o
szokas), a harmadik es a negyedik parameter a vegrehajtando parancs egyeb parametereit
tartalmazza. A (char *)0 a programnak atadando parameter-felsorolas veget jelzi. Az
utolso (envp) parameter az uj programnak atadando shell-valtozokra mutat.
Az exec() rendszerh vasok vegrehajtasukkor ellen}rzik, hogy a vegrehajtando fajl rwxo
bitjei kozul az x-bit be van-e all tva, az uj folyamat befer-e meg a memoriaba. Ha a
fenti feltetelek nem teljesulnek, akkor az exec rendszerh vas sikertelen lesz (ezert kell
gyelni az exec rendszerh vas visszateresi erteket). (Az exec rendszerh vas nem zarja le
automatikusan a korabban hasznalt fajlokat! A megnyitott fajlokat az ujabb, exec-elt
program tovabb hasznalhatja.)
Ha egy szul}-folyamat megszul egy gyermek-folyamatot, majd a gyermek elvegzi
o
a feladatat, akkor a gyermeknek meg kell h vnia az exit() rendszerh vast. Az exit
rendszerh vasnak egyetlen parametere van, egy 0 es 255 koze es} egesz szam, az un.
o
exit-statusz. A szul} folyamat lekerdezheti a gyermek-folyamat exit-statuszat, es
o
ebb}l peldaul arra kovetkeztethet, hogy a gyermek-folyamat milyen eredmennyel tudta
o
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a feladatat ellatni. A szul}-folyamat a gyermek- folyamat befejez}desere a wait() rendo
o
szerh vas seg tsegevel varakozhat. A wait() rendszerh vas egyetlen parametere egy egesz
t pusu valtozora mutat, es a rendszerh vas vegrehajtasa utan a befejez}dott gyermeko
folyamat exit-statusza kerul a megadott valtozo magasabb helyiertek} bytejaba. Ha a
u
gyermek-folyamat vegrehajtotta az exit() rendszerh vast, a szul} pedig meg nem adta
o
ki a wait rendszerh vast, akkor a gyermek-folyamat altalaban un. zombie-processz
lesz, vagyis az altala lefoglalt memoria felszabadul, de a processz-tablaban meg foglalja a
helyet. (Ha egy szul}-folyamat nem hajt vegre egyetlen wait()-et sem, akkor el}bb- utobb
o
o
betelhet a processz-tabla, es a rendszer nem lesz kepes ujabb folyamatokat elind tani.)
A fenti rendszerh vasokat peldaul a kovetkez}keppen hasznalhatjuk:
o
main(argc, argv, envp)
int argc
char **argv, **envp
{
int eredm
/*
.
.
.
*/
if (fork() == 0) {
execle("/bin/ls","ls","-l",(char *)0,envp)
} else {
wait(&eredm)
}
}

A fenti program elind t egy gyermek-folyamatot, amely vegrehajtja a UNIX ls
parancsat, es a szul} megvarja, am g a gyermek-folyamat befejez}dik. Lenyegeben a
o
o
UNIX shelljei is gy m}kodnek (ezt kes}bb egy reszletesebb peldan is megnezhetjuk).
u
o
A getpid() es a getppid() rendszerh vasok kozul az el}bbi az }t vegrehajto folyamat
o
o
pid-jet, az utobbi pedig az ot vegrehajto folyamatszul}-folyamatanaka pid-jet adja vissza
}
o
(mindket fuggveny egesz t pusu erteket ad vissza).
A setpgrp() rendszerh vas az }t vegrehajto folyamat folyamat-csoport azonos tojat a
o
folyamat azonos tojara (pid-jere) all tja, es az uj folyamat-csoport azonos tot adja vissza.
A folyamat-csoport azonos to azert hasznos, mert a kill() rendszerh vassal signal-t lehet
kuldeni egy folyamat-csoport minden egyes tagjanak (ld. kes}bb).
o
A nice() rendszerh vassal lehet egy folyamat utemezesi prioritasat modos tani. Az
alapertelmezes szerinti prioritasi ertek 20 ezt az erteket novelve csokken a folyamat
prioritasa. A nice() parametereben megadott erteket az operacios rendszer hozzaadja
a folyamat prioritasahoz. Negativ parametert csak szuperfelhasznalo jogu folyamatoktol
fogad el az operacios rendszer.
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3.2 A fajlrendszer rendszerh vasai
A fajlrendszer-kezel} rendszerh vasok a kovetkez}k: access(), creat(), open(),
o
o
close(), read(), write(), lseek(), stat(), fstat(), dup(), pipe(), link(),
unlink(), mount(), umount(), sync(), chdir(), mkdir() es az rmdir(). Fontos
megeml teni, hogy ezek a rendszerh vasok nem azonosak a C szabvanyos I/O konyvtar
fopen(), fclose(),
fuggvenyeivel. Ha lehet, akkor ne keverjuk egy programon belul a
fenti ket fuggvenycsoportot, mert meglepetesek erhetnek! (Ha lehet, akkor a szabvanyos
I/O konyvtarat hasznaljuk, mert a programunk hordozhatobb lesz. Az open(), close(),
rendszerh vasok altalaban csak a UNIX rendszerekben vannak meg, m g az fopen(),
fclose()
rutinok gyakorlatilag minden C nyelvi kornyezetben elerhet}k.)
o
:::

:::

:::

3.2.1 Alapvet}, fajlokkal kapcsolatos rendszerh vasok
o

Az access() rendszerh vassal lehet lekerdezni az operacios rendszert}l azt, hogy egy
o
adott fajlon egy adott m}veletet elvegezhetunk-e. Lekerdezhetjuk, hogy egy adott nev}
u
u
fajl letezik-e, olvashatjuk-e, rhatjuk-e illetve vegrehajthatjuk-e azt. Az ellen}rzes nem
o
az e ektiv user- ill. group-id alapjan tortenik.
A creat() es az open() rendszerh vas foglalkozik a fajlok megnyitasaval. A creat()
letrehoz egy, az els} parametereben megadott nev} fajlt, ha eddig az adott nev} fajl nem
o
u
u
letezett ha pedig az els} parametereben megadott fajl mar letezik, akkor annak a hosszat
o
0 bytera all tja. A creat() rendszerh vas visszateresi erteke egy egesz t pusu ertek, egy
un. fajldeszkriptor. Ezzel lehet kes}bb a fajlm}veleteknel erre a fajlra hivatkozni. A
o
u
creat() ezenk vul beall tja a masodik parametereben megadott ertek szerint az uj fajl
vedelmi bitjeit.
Az open() rendszerh vas egy mar meglev} fajlt nyit meg rasra vagy olvasasra. A
o
megnyitando fajl neve az open() els} parametere, a masodik parameter erteke altalaban
o
0, ha a fajlt olvasasra nyitjuk meg 1, ha a fajlt rni akarjuk (ezeknek megfelel} konstansok:
o
az O RDONLY, O WRONLY illetve O RDWR, amelyek az <fcntl.h> nev} header-fajlban vannak
u
deklaralva). Ennek a visszateresi erteke szinten egy fajldeszkriptor.
A close() rendszerh vas a parametereben megadott fajldeszkriptorhoz tartozo fajlt
lezarja. Itt erdemes megjegyezni azt, hogy minden egyes folyamat fajldeszkriptorjai
0-tol kezd}d}en vannak sorszamozva, es ha egy uj fajlt megnyitunk, akkor mindig a
oo
legkisebb "ertek}" fajldeszkriptor lesz a fajlhoz rendelve. (Ez azt jelenti, hogy ha pl.
u
a 0-as fajldeszkriptort lezarjuk, akkor a kovetkez} open() rendszerh vas a megnyitott
o
fajlt a 0-as fajldeszkriptorhoz fogja kotni. Minden program elindulasakor harom "szabvanyosan" megnyitott fajlon dolgozhat: a 0-as deszkriptoru szabvanyos bemeneten,
az 1-es deszkriptoru szabvanyos kimeneten es a 2-es deszkriptoru szabvanyos hibacsatornan. Alaphelyzetben ezek a terminalhoz (billenty}zethez ill. keperny}hoz) vannak
u
o
rendelve, de a shell-ben ezek atirany thatoak tetsz}leges fajlba.)
o
A kovetkez} lenyeges rendszerh vasok: a read() es a write() rendszerh vasok.
o
Ezekkel lehet egy mar megnyitott fajlon valamilyen m}veletet vegezni: a fajlbol adau
tokat olvasni, es a fajlba adatokat rni. Mindket rendszerh vas els} parametere ano
nak a fajlnak a fajldeszkriptorja, amelyen az adott fajlm}veletet el akarjuk vegezni.
u
A masodik parameter tartalmazza annak az adatteruletnek a c met, ahonnan az adatokat a fajlba akarjuk rni (ill. read rendszerh vasnal: ahova a fajlbol olvasni akarunk).
Az utolso parameter a fenti adatterulet hosszat tartalmazza, vagyis a maximalisan be-
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olvasando (ill. ki rando) byteok szamat. Ezeknek a rendszerh vasoknak egesz t pusu
a visszateresi erteke, es a visszateresi ertek megadja a rendszerh vas soran tenylegesen
ki rt ill. beolvasott byteok szamat. (Peldaul ha a read() rendszerh vas fajlvegehez er, es
nincs a fajlban mar annyi karakter, amennyit a rendszerh vas harmadik parametereben
megadtunk, akkor csak annyi karaktert fog beolvasni, amennyi a fajlban van, es ennek
megfelel}en a visszateresi erteke kisebb lesz a harmadik parameter ertekenel).
o
A fenti rendszerh vasok hasznalatara lathatunk peldat a kovetkez} proo
gramreszletben:
fggv()
{
int fd1,fd2
char buf 512]
int rc
fd1=open("/usr/csb/filenev",0) /* 0 = olvasasra nyitom meg */
fd2=creat("/usr/csb/ujfile",0644) /* rw-r--r-- biteket \'all\'\i t */
/*
Az fd1 filebol atmasoljuk az fd2 fileba maximum az elso 512
darab karaktert.
*/
rc=read(fd1,buf,512)
if (rc>0) write(fd2,buf,rc)
/*
...
*/
close(fd2)
close(fd1)
}

A lseek() rendszerh vassal lehet egy fajlban "poz cionalni" (ahol a poz cionalas
ertelmezett) ugy, hogy pl. a kovetkez} read() onnan kezdi el olvasni a fajlt, ahova
o
poz cionaltunk. A lseek rendszerh vasnak harom parametere van: az els} es a harmadik
o
egesz, a masodik pedig (C-ben) long t pusu (ezt a programban a konstansok megadasakor
ne feledjuk el!). Az els} parameter annak a fajlnak a deszkriptorat tartalmazza, amelyo
ben poz cionalni akarunk. A masodik parameter tartalmaz egy "poz ciot" (pl. lehet,
hogy azt tartalmazza, hogy a fajl hanyadik karakterere akarunk poz cionalni). Ha a harmadik parameter SEEK_SET, akkor a fajlban arra a karakterre kell poz cinalni, amelynek a
poz ciojat a masodik parameter tartalmazza. Ha a harmadik parameter SEEK_CUR, akkor
a fajlban beall tando poz cio egyenl} az aktualis poz cionak es a masodik parameternek
o
az osszegevel. Ha pedig a harmadik parameter erteke SEEK_END, akkor az uj fajlpoz cio
egyenl} lesz a fajl hosszanak es a masodik parameternek az osszegevel. A rendszerh vas
o
visszateresi erteke long t pusu, es az uj aktualis fajlpoz ciot tartalmazza. Megjegyezzuk,
hogy a SEEK_SET, SEEK_CUR, SEEK_END makrok (konstansok) az <unistd.h> headerfajlban vannak de nialva.
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3.2.2 A fajlrendszer es a memoriakezel} kapcsolata
o

A UNIX operacios rendszer ujabb valtozatai lehet}seget adnak a fajlok memorian
o
keresztul torten} eleresere a fajlnak a memoriaba agyazasaval (ezzel lehet}seg ny lik
o
o
a fajl tartalmanak memoriam}veletek seg tsegevel torten} modos tasara, amely gyakran
u
o
hatekonyabb a hagyomanyos read() illetve write() rendszerh vasoknal.) Erre az mmap()
UNIX rendszerh vast hasznalhatjuk, melynek protot pusa a kovetkez}:
o
caddr_t mmap(caddr_t addr, size_t len, int prot, int flags,
int fd, off_t offset)

Az mmap() rendszerh vas els} parametere caddr_t t pusu (az ilyen t pusu valtozok egy
o
tetsz}leges memoriac met kaphatnak ertekul, altalaban char * t pussal implementaljak).
o
Az els} argumentumban azt a memoriac met kell megadnunk, ahova be akarjuk agyazni a
o
kerdeses fajlt (vagy annak egy reszet). A programok hordozhatosaga erdekeben itt 0-t adjunk meg, ugyanis ekkor az operacios rendszer maga valaszt egy szabad memoriateruletet,
ahova a fajlt beagyazza. Sikeres vegrehajtas eseten az mmap() rendszerh vas az fd
argumentumban kijelolt fajldeszkriptoru fajl offset argumentumaban adott poz ciotol
kezd}d} len argumentumban bajtokban megadott hosszu reszet beagyazza, es a rendoo
szerh vas visszateresi erteke a beagyazott fajl-resz memoriabeli kezd}c me (a beagyazas
o
kezd}c me).
o
A prot parametert a PROT_READ, PROT_WRITE, PROT_EXEC szimbolikus konstansok bitenkenti VAGY m}velettel kepzett kapcsolataval all thatjuk el} aszerint, hogy
u
o
a beagyazott fajl-reszen milyen m}veleteket akarunk megengedni (olvasni, rni vagy
u
vegrehajtani akarjuk a reszeit). Ha egy fajlra nincs rasi engedelyunk a hozza tarolt
rwx-bitek alapjan, akkor a memoriaba agyazassal sem modos thatjuk azt.
A flags argumentum erteke vagy MAP_PRIVATE vagy pedig MAP_SHARED lehet
(altalaban). Ha itt MAP_PRIVATE-et adunk meg, akkor a fajlon vegzett modos tasok
id}legesek, azaz az eredeti fajlon nem jelennek meg, a fajl tobbi felhasznaloja nem latja
o
azokat.
#include
#include
#include
#include

<stdio.h>
<sys/types.h>
<sys/mman.h>
<fcntl.h>

main()
{
int fd
char *ra
fd=creat("cmmap1t",0666)
write(fd,"alma",4)
close(fd)
fd=open("cmmap1t",O_RDWR)
ra=mmap(0,4,PROT_WRITE|PROT_READ,MAP_SHARED,fd,0)
if (ra == (caddr_t)(-1)) perror("mmap sikertelen")
*(ra+2)='f'
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munmap(ra,4)
close(fd)
}

3.3 Egyeb, fajlokkal kapcsolatos rendszerh vasok
A stat() es fstat() rendszerh vassal fajloknak kulonfele jellemz}it lehet lekerdezni.
o
Mindket rendszerh vas els} parametere azt tartalmazza, hogy melyik fajlrol akarunk
o
b}vebb informaciot: az fstat() els} parametere egy megnyitott fajlra vonatkozo
o
o
fajldeszkriptor, m g a stat() rendszerh vas els} parametere egy string, amely egy abo
szolut vagy relat v fajlnevet tartalmaz. Mindket rendszerh vas masodik parametere egy
stat t pusu strukturara mutato pointer. Ebben a strukturaban adja vissza az operacios
rendszer a fajlrol a kovetkez} informaciokat:
o
struct stat {
short int st_dev
unsigned short st_ino
unsigned short st_mode
short int st_nlink
short int st_uid
short int st_gid
short int st_rdev

long st_size
long st_atime
long st_mtime
long st_ctime

/* Melyik periferian van a filet tartalmazo
directorybejegyzes */
/* Hanyas a file inode-janak a sorszama*/
/* Egyeb dolgok, pl. rwx-bitek */
/* Hany link kapcsolodik a filehoz */
/* A file tulajdonosanak uid-je */
/* A file tulajdonosanak gid-je */
/* A blokk/karakter-specialis fileoknal ez
tartalmazza a hozza tartozo I/O egyseg
belso sorszamat */
/* A file meretet tartalmazza */
/* A file legutolso hasznalatanak a
datumat tartalmazza */
/* Az utolso modositas datuma */
/* A file letrehozasanak a datuma */

}

A kovetkez} pelda bemutatja a stat() hasznalatat:
o
/*
* Megallapitja az egyetlen parametereben atadott file tipusat.
*/
#include <sys/types.h>
#include <sys/stat.h>
main(argc,argv)
int argc
char **argv
{
struct stat tmpstat
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if (argc != 2) {
printf("Usage: %s filename\n",argv 0])
exit(-1)
}
if (stat(argv 1],&tmpstat) < 0) {
perror("stat")
exit(-1)
}
printf("%s: ",argv 1]) /* Filenevet kiirom */
switch (tmpstat.st_mode & S_IFMT) {
case S_IFDIR: printf("directory")
break
case S_IFCHR: printf("karakter-specialis file")
break
case S_IFBLK: printf("blokk-specialis file")
break
case S_IFREG: printf("kozonseges file")
break
default:
printf(" ?")
break
}
printf("\n")
}

A dup() rendszerh vas egyetlen parametere egy megnyitott fajlra mutato
fajldeszkriptor. Visszateresi erteke egy masik fajldeszkriptor lesz, amely ugyanarra a
fajlra vonatkozik, mint amit a parametereben megadtak (barmelyik fajldeszkriptoron is
olvasunk, a fajlbol egy karaktert csak egyszer fogunk beolvasni, mivel a fajlbeli poz cio a
ket deszkriptornal mindig meg fog egyezni).
A pipe() rendszerh vas seg tsegevel a mar korabban is megeml tett pipe-okat tudjuk
letrehozni. Ennek a parametere egy olyan ket-elem} tomb, amelynek mindket eleme
u
egesz t pusu, es a rendszerh vas vegrehajtasa utan egy-egy fajldeszkriptort tartalmaz.
Amit az 1-es index} tombelemben lev} fajldeszkriptoru leba runk, azt a 0-as index}
u
o
u
tombelemben lev} fajldeszkriptoru fajlbol olvashatjuk ki. Ennek a hasznalatara pelda a
o
kovetkez} programreszlet:
o
#include <stdio.h>
main()
{
int pfd 2]
int szam
/*
.
.
*/
pipe(pfd)

/* A pipe filedeszkriptorjai ebbe a tombbe kerulnek*/
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if (fork() == 0) {
close(pfd 0])
close(1)
dup(pfd 1])
/* standard output:=pipe file */
close(pfd 1])
printf("%d",23) /* Elkuldjuk a masik folyamatnak */
} else {
close(pfd 1])
close(0)
dup(pfd 0])
/* Uj standard input: masik folyamattol */
close(pfd 0])
scanf("%d",&szam) /* Fogadjuk a masik folyamat outputjat */
}
/*
.
.
*/
}

A link() rendszerh vassal lehet egy fajlra vonatkozo linket letrehozni, az unlink()
rendszerh vassal pedig egy link megszuntethet} (vagyis a felhasznalo ezt ugy latja, hogy
o
a fajl a directoryjabol torl}dik). A link-nek ket string t pusu parametere van, az els}
o
o
annak a letez} fajlnak neve, amelyre a letrehozando link mutasson a masodik pedig az
o
ujonnan letrehozando fajl nevet tartalmazza. Ha egy mas felhasznalo fajljait (egyenkent
...) meglinkeljuk megunknak, akkor a fajlhoz hozzaferhetunk, de a vedelmi bitjeit nem
valtoztathatjuk meg! Az unlink() egyetlen parametere a torlend} fajl neve.
o
A mount() rendszerh vassal lehet egy fajlrendszert "beilleszteni" valamelyik directory ala. Legyen peldaul egy 286-os AT-n az els} lemezegysegnek a UNIX alatti neve:
o
/dev/fd0. Ha a benne lev} lemez egy ervenyes directory-strukturat (fajlrendszert) taro
talmaz, es azt valamelyik winchesteren lev} directory ala be akarjuk rakni, akkor egy
o
ilyesmi rendszerh vast kell kiadni:
mount("/dev/fd0","/usr/csb/aldir",0)

A mount rendszerh vas altal beillesztett fajlrendszert az umount() rendszerh vassal
lehet a rendszerb}l "kiilleszteni". Ennek alkalmazasara tekintsuk a kovetkez} proo
o
gramreszletet:
umount("/dev/fd0")

(A mount() es az umount() rendszerh vasokat csak a rendszergazda adhatja ki!)
A sync() rendszerh vassal lehet a cache-memoriaban tarolt "aktualizalt"
lemezblokkokat a lemezre zikailag kiiratni (a rendszerh vasnak nincsenek parameterei).
A chdir() rendszerh vassal lehet az aktualis directoryt (munkadirectoryt) beall tani.
Egyetlen parametere az uj munkadirectory nevet tartalmazza.
Az mkdir() ill. rmdir() rendszerh vasokkal lehet egy uj directoryt letrehozni, ill. egy
meglev} directoryt torolni. Mindket rendszerh vas egyetlen parametere a letrehozando
o
(ill. torlend}) directorynak a neve.
o
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3.4 Fajlok konkurrens elerese
Ebben a reszben arrol lesz szo, hogy a UNIX milyen szolgaltatasokat nyujt parhuzamos
folyamatok fajlhozzaferesenek a szinkronizalasara. A UNIX a fajlok konkurrens
kezelesekor kialakult problemas helyzeteket a korabban mar ismertetett rekord-lefoglalas
lehet}seget biztos tja. A rekord-lefoglalas az fcntl() rendszerh vas seg tsegevel impleo
mentalhato a kovetkez}kben le rtak szerint (az fcntl() hasznalatahoz szukseg van az
o
<fcntl.h> fajl include-olasara is).
A UNIX rekord-lefoglalasa ketfele lehet: rasi vagy olvasasi celu. A kett} kozotti
o
lenyeges kulonbseg az, hogy egy rekordteruletet (azaz a fajl egy bizonyos intervallumat)
ras celjabol egyszerre legfeljebb csak egy folyamat foglalhatja le, es csak akkor, ha azt
a reszt senki mas nem foglalta meg le sem rasi sem pedig olvasasi szandekkal) tovabba
meg kell eml teni, hogy olvasasi celu rekordterulet lefoglalast egyidej}leg tobb folyamat is
u
kerheti akar ugyanarra a rekord-teruletre is. Fontos tudni, hogy a parhuzamos folyamatok
kolcsonos kizarasa az fcntl() rendszerh vasnal valosul meg, es nem a fajlm}veleteknel:
u
vagyis ha valamelyik folyamat nem tartja be a rekord-lefoglalasi szabalyokat, akkor az
operacios rendszer megengedi neki, hogy kedve szerinti modos tasokat illetve olvasasokat
vegezzen a fajlon, de az eredmeny korrektseget ilyenkor nem lehet garantalni.
Az fcntl() rendszerh vas a kovetkez}keppen hasznalhato:
o
struct flock lock_data
int fd, cmd, rc
...
rc=fcntl(fd,cmd,&lock_data)

A rendszerh vas hatasara az fd fajldeszkriptorral azonos tott fajl lock_data argumentumban megadott resze a cmd argumentumban megadott modon lefoglalasra kerul.
A rendszerh vas rasi celu rekord-lefoglalas eseten sikertelen lesz, ha a fajlra nincs rasi
engedelyunk.
A rekordlefoglalas modja (a cmd argumentum erteke alapjan) haromfele lehet:
: ennek hatasara a lock_data argumentumban kijelolt reszre vonatkozo
rekord-lefoglalasi informaciokat kapphatjuk vissza (az operacios rendszer ekkor
kitolti az aktualisan ervenyes rekord-lefoglalasi informacioi alapjan a lock_data
struktura megfelel} mez}it { ld. kes}bb).
o o
o
F_SETLK : ennek hatasara az operacios rendszer modos tja a fajlra vonatkozoan
tarolt rekord-lefoglalasi informacioit, vagyis ezzel lehet egy-egy rekordteruletet
lefoglalni vagy egy korabban kert lefoglalasi kerelmet hatastalaln tani. A
lock_data struktura ltype komponensenek erteke alapjan a kovetkez} rekordleo
foglalast vegezhetjuk el:
{ F_RDLCK : ha ezt az erteket all tjuk be, akkor olvasasi cellal foglalhatjuk le a
tobbi strukturakomponensben speci kalt fajl-rekordot.
{ F_WRLCK : ha ezt az erteket all tjuk be, akkor rasi cellal foglalhatjuk le a tobbi
strukturakomponensben speci kalt fajl-rekordot.
F_GETLK
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{

: ha ezt az erteket all tjuk be, akkor a tobbi strukturakomponensben
speci kalt fajl-rekordra vonatkozoan a korabbiakban kiadott rekord-lefoglalasi
kerelmet vonhatjuk vissza, ervenytelen thetjuk.
Megjegyezzuk, hogy ha a rekordlefoglalasi igeny a rendszerh vas vegrehajtasanak
pillanataban nem kieleg thet}, akkor a rendszerh vas sikertelen visszateresi ertekkel
o
ter vissza a rekordlefoglalasi igeny kieleg tese nelkul.
F_SETLKW : ez ugyanazt teszi, mint az F_SETLK, de ez a folyamatot megvarakoztatja
olyan esetben, amikor a rekord-lefoglalasi igenye nem kieleg thet}. A folyamat
o
egeszen addig var, am g a rekordlefoglalasi igenyei ki nem eleg thet}k, majd a
o
rendszerh vas visszateresekor a megfelel} rekordlefoglalasi igenyeket az operacios
o
rendszer ervenyes tette.
F_UNLCK

Most attekintjuk a lock_data argumentum egyes komponenseinek a szerepet (vagyis
azt, hogy az flock struktura egyes komponensei mit hogyan rhatnak le):
struct flock
short
short
off_t
off_t
pid_t
}

{
l_type
l_whence
l_start
l_len
l_pid

: erteke a korabbiakban rtak alapjan F_RDLCK vagy F_WRLCK vagy pedig
lehet.
l_whence : erteke SEEK_SET vagy SEEK_CUR vagy SEEK_END lehet aszerint, hogy az
l_start argumentum kezd}poz ciojakent a fajl elejet vagy az aktualis fajlpoz ciot
o
vagy pedig a fajl veget kell-e tekinteni.
l_start : erteke a lefoglalando rekordterulet kezd}poz ciojat adja meg. Ez egy
o
byte-ban mert o szet az l_whence-hez mind kezd}poz ciohoz kepest.
o
l_len : itt kell megadni a lefoglalando rekordterulet hosszat byteokban merve. Ha
itt 0 erteket adunk meg, akkor a fajl vegeig az egesz fajl tartalmat foglaljuk le, akar
a kes}bb hozzaf}zott adatokkal egyutt is.
o
u
l_pid : az F_GETLK itt adja vissza a tobbi komponensben speci kalt rekordteruletet
lefoglaltan tarto folyamat azonos tojat.
l_type
F_UNLCK

A rekordlefoglalas hasznalatara lassuk a kovetkez} peldat:
o
#include <fcntl.h>
#include <stdio.h>
main(int argc, char **argv)
{
struct flock lock_data
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int fd, cmd, rc, rf
fd=open("probafile",O_RDWR)
rf=fork()
lock_data.l_whence=SEEK_SET
lock_data.l_start=0
lock_data.l_len=10
if (rf==0) {
lock_data.l_type=F_RDLCK
rc=fcntl(fd,F_SETLK,&lock_data) /* gyermek */
fprintf(stderr,"Gyermek tovabbfutott!\n")
sleep(5)
lock_data.l_type=F_UNLCK
rc=fcntl(fd,F_SETLK,&lock_data) /* gyermek */
} else {
sleep(1)
fprintf(stderr,"Szulo: elkezd futni a lock elott ...\n")
lock_data.l_type=F_WRLCK
rc=(-1)
while (rc==(-1)) {
rc=fcntl(fd,F_SETLK,&lock_data) /* szulo */
if (rc==(-1)) fprintf(stderr,"Szulo: SETLK sikertelen ... ujraprobalom\n")
sleep(1)
}
fprintf(stderr,"Szulo lockolt es tovabbfutott!\n")
}
close(fd)
}

A program elindulasa el}tt hozzunk letre egy probafile nev} fajlt, amire van rasi
o
u
jogunk (en ezt ugy tettem, hogy a gepem jelszofajljat atmasoltam erre a nevre abba a
directoryba, ahol a programot futtatni akartam).
A program elindulasa utan ketteagazik: szul egy gyermekfolyamatot. A gyermek
lefoglalja olvasasi cellal a probafile fajl els} 10 karakteret, es var 5 masodpercig, mialatt
o
a lefoglalast fenntartja, majd 5 masodperc utan a lefoglalast megsz}nteti, majd lezarja a
u
fajlt. A szul} var 1 masodpercet, majd ciklusban masodpercenkent egyszer megprobalja
o
lefoglalni a fajl els} 10 karakteret rasi cellal.
o
A program futtatasakor a kovetkez}ket rja ki a szabvanyos hibacsatornara:
o
Gyermek tovabbfutott!
Szulo: elkezd futni a lock elott ...
Szulo: SETLK sikertelen ... ujraprobalom
Szulo: SETLK sikertelen ... ujraprobalom
Szulo: SETLK sikertelen ... ujraprobalom
Szulo: SETLK sikertelen ... ujraprobalom
Szulo lockolt es tovabbfutott!

Ez erthet}, mert a szul} folyamat 1 masodpercet var, majd utana probalja meg
o
o
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lefoglalni 1 masodpercenkent a fajlt, es ez csak azutan sikerul, miutan a gyermeke a fajlt
mar nem foglalja olvasasi cellal.

3.5 Kiveteles esemenyek kezelesenek rendszerh vasai
Ebbe a csoportba tartoznak a kovetkez} rendszerh vasok: signal(), kill() es az
o
alarm(), valamint a POSIX 1003.1-konform rendszerekben nehany mas rendszerh vas.
Ebben a reszben el}szor bemutatjuk a kiveteles esemenyek kezelesere bevezetett signal
o
absztrakciot, majd bemutatjuk a hagyomanyos UNIX eszkozoket e kiveteles esemenyek
kezelesere, vegul megmutatjuk a POSIX 1003.1 szabvany ide vonatkozo modos tasait,
amelyek a hagyomanyos UNIX eszkozok tervezese soran elkovetett hibak elkerulese
erdekeben keszultek.

3.5.1 A signalok feladata

A signalok lenyegeben a megszak tasoknak a magasabb szint} megfelel}i (nevezhetjuk
u
o
o
}ket szoftver-megszak tasoknak is). Egy signalt egy program vagy az operacios rendszert}l, vagy egy masik programtol (folyamattol ...) kaphat ( gy ez is tekinthet}
o
o
parhuzamos programok kommunikacios eszkozenek). Tobbfajta signal is van (pl. a
BREAK billenty} lenyomasakor egy un. SIGINT nev} signal generalodik a programu
u
nak).

3.5.2 Hagyomanyos signalkezelesi technikak

A programok szabadon rendelkezhetnek arrol, hogy egy adott fajtaju signallal mit akarnak csinalni. Erre valo a signal rendszerh vas. Ennek els} parametere a signal-fajtat
o
adja meg, masodik pedig megmondja, hogy mit kell az olyan fajta signalokkal csinalni
(lehetseges ertekei: SIG IGN = a signalt nem kell gyelembe venni SIG DFL = a rendszerben alapertelmezesnek szam to dolgot kell csinalni ezenk vul megadhatjuk a program egy
eljarasanak a c met is, amely az adott t pusu signalok eseten lesznek megh vva). Pelda:
signal(SIGINT, SIG_IGN)

/* Nem fogadom ezutan a SIGINT-et */

A UNIX rendszerben a fontosabb signalok a kovetkez}k:
o
SIGHUP : Megszakadt a felhasznaloi terminal es a gep kozotti kapcsolat
SIGINT : "DEL" billenty}t megnyomtak
u
SIGQUIT : Ctrl- billenty}t megnyomtak
u
SIGILL : A processzor "illegal instruction"-t talalt
SIGIO : Egy aszinkron I/O esemeny bekovetkezeser}l kapunk ezzel ertes test.
o
SIGFPE : A lebeg}pontos szam tasokat vegz} egyseg valami kiveteles esetet jelez.
o
o
SIGKILL : A folyamatot meg akarjak all tani (ezt a signalt nem lehet ignoralni
vagy elkapni!)
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SIGSEGV : A program megszegte a szegmentalasi szabalyokat
SIGPIPE : Olyan pipe-ra akarunk rni, amit senki sem olvas
SIGPWR : Aramkimaradas van (a rendszer ilyenkor altalaban szunetmentes
tapegysegr}l megy, es hamarosan leallasa varhato).
o
SIGALRM : Korabban alarm() rendszerh vassal kert signal megerkezese
SIGCLD : A folyamat egy gyermek-folyamata befejez}dott.
o
SIGURG : A folyamat surg}snek min}s tett adatokat kap (ld. kes}bb a halozatokrol
o
o
o
szolo reszt).
SIGUSR1 : A signal jelenteset a felhasznalo (programozo) szabadon de nialhatja.
SIGUSR2 : A signal jelenteset a felhasznalo (programozo) szabadon de nialhatja.
SIGSYS : A folyamat egy ismeretlen rendszerh vast hajtott vegre.
(Ezeken k vul mas signal-ok is vannak, de ez most nem erdekes.)
A kill() rendszerh vassal lehet egy signalt kuldeni egy folyamatnak. A rendszerh vas
els} parametere az elkuldend} signal t pusa, a masodik arameter pedig annak a folyao
o
matnak az azonos toja, akinek a signalt szantuk. (Ha a pid negat v, akkor a signal minden olyan folyamatnak el lesz kuldve, amelynek a folyamat-csoport azonos toja egyenl}
o
pid argumentumanak abszolutertekevel.) Van egy specialis t pusu signal, a SIGALRM.
Ezt lehet az alarm() rendszerh vassal generalni. Az alarm() egyetlen parametere egy
egesz szam. Abban az egesz szamban kell megadni az operacios rendszernek, hogy hany
masodperc mulva kuldjon a folyamatunknak egy SIGALRM signalt.

3.5.3 POSIX signal-szemantika

A POSIX signal-feldolgozast irany to rutinjait ugy terveztek, hogy azok alapvet}en
o
signal-halmazokkal foglalkozzanak: ehhez bevezettek a sigset t adatt pust, mely
adatt pushoz de nialtak a manipulaciojara hasznalhato m}veleteket is. Ezek a m}veletek
u
u
a kovetkez}k1 :
o
int
int
int
int
int

sigemptyset(sigset_t *set)
sigfillset(sigset_t *set)
sigaddset(sigset_t *set,int sig)
sigdelset(sigset_t *set,int sig)
sigismember(sigset_t *set,int sig)

A sigemptyset() fuggveny az argumentumaban megadott signal-halmazt uresre
all tja, azaz olyan allapotura, hogy egyetlen signal sem kerul bele. A sigfillset()
fuggveny az argumentumaban megadott signal-halmazt olyan ertek}re all tja be, hogy a
u
rendszerben az osszes de nialt signal-t pus benne legyen. A sigaddset() fuggvennyel
1 Ezekre a m} veletekre azert van szukseg, mert a signalok implementaciofugg} { esetleg tulsagosan nagy
u
o
{ szama miatt nem lehet minden architekturan egyforman implementalni { mondjuk egeszekkel, es az ilyen
adatt pusok kezelese esetleg nem lenne hordozhato, ezert e le ras kereteben ezt kerulni fogom.
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lehet az els} argumentumaban megadott signal-halmazba a masodik argumentumban
o
megadott signal-t pust betenni a sigdelset() fuggvennyel pedig az els} argumeno
tumaban lev} signal-halmazbol a masodik argumentumaban megadott signalt kivenni.
o
A sigismember() fuggveny visszateresi erteke 1 (igaz), ha az els} argumentumaban
o
megadott signal-halmaz tartalmazza a masodik argumentumaban megadott signalt.
A POSIX szabvany de nialja a maszkolt signalok fogalmat: ez egy folyamatonkent
(processzenkent) nyilvantartott attributum, mely tartalmazza az osszes olyan signalt,
amelyeket a folyamat blokkolt, vagyis azokat a signalokat, amelyeknek a kivaltasat
a folyamat megtiltotta (az operacios rendszernek). Termeszetesen egy folyamatnak
kuldhetnek olyan signalokat, amiket az eppen blokkolt, de azoknak a kivaltasaval az
operacios rendszervarni fog a blokkolas befejezeseig. Az ilyen signalokat, amiket egy
folyamat blokkol, de kuldott mar neki valaki: varakozo signaloknak is nevezik.
Az egyes signalok kezelesenek mikentjet a sigaction() rendszerh vassal jelolhetjuk
ki. Ennek parameterezese a kovetkez}:
o
int sigaction(int sig, const struct sigaction *newact,
struct sigaction *oldact)

A sigaction() rendszerh vas els} argumentuma azt hatarozza meg, hogy melyik
o
signal kezeleset akarjuk megvaltoztatni vagy lekerdezni2 A masodik argumentumban
lehet kijelolni az els} argumentumban megadott signal-t pus uj (mostantol ervenyes)
o
kezelesmodjat, illetve ott NULL pointert megadva a rendszerh vas nem modos tja a signal
eppen ervenyes kezelesmodjat. A harmadik argumentumban (ha ott nem NULL erteket
adunk at) az operacios rendszer visszaadja a signal eddigi kezelesenek modjara vonatkozo
informaciokat.
A signal-kezeles modjat le ro struct sigaction struktura felep tese a kovetkez}:
o
struct sigaction {
void (*sa_handler)()
sigset_t sa_mask
int sa_flags
}

Az sa handler komponense erteke vagy a SIG IGN vagy SIG DFL szimbolikus konstansok valamelyike (lasd reszletesebben a 3.5.2 pontot), vagy pedig a signal-kezel}
o
fuggveny c me lehet. Ha egy signal-kezel} fuggveny van az sa handler kompoo
nensben, akkor az sa mask komponens a signal-kezel} fuggveny futasa alatt a meg
o
maszkolando signalok halmazat kell, hogy tartalmazza (vagyis a signal-kezel} futasakor
o
a maszkolt signalok halmaza ki fog b}vulni az sa mask halmazban megadott sigo
nalokkal, a signal-kezel} lefutasanak vegeig). Az eppen kivaltott signal automatikusan
o
belekerul az sa mask halmazba, gy azt nem kell belerakni abba. Az sa flags a signalkezeles folyamatat befolyasolja, es a POSIX az egyetlen SA NOCLDSTOP lehetseges aget
de nialja a kovetkez}keppen: ha ez be van all tva, akkor az operacios rendszer nem fog
o
SIGCHLD3 signalt generalni olyankor, amikot a folyamat valamely gyermek-folyamatanak
felfuggeszt}dik vagy tovabb folytatodik a futasa.
o
Lehet}seg van az eppen maszkolt signalok halmazanak lekerdezesere es modos tasara
o
is: erre hasznalhato a sigprocmask() rendszerh vas. Ennek protot pusa a kovetkez}:
o
2
3

A sigaction() rendszerh vas hasznalhato a signal eppen ervenyes kezelesmodjanak lekerdezesere is.
A SIGCHLD a Berkeley UNIX SIGCLD signaljanak a megfelel}je az AT&T System V UNIX rendszereben.
o
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int sigprocmask(int hogyan, const sigset_t *newset, sigset_t *oldset)

Az els} argumentum erteke haromfele lehet: vagy SIG BLOCK vagy SIG UNBLOCK vagy
o
pedig SIG SETMASK. SIG BLOCK ertek eseten a masodik (newset) argumentumban lev}
o
signalok hozzaadodnak a maszkolt signalok halmazahoz. SIG UNBLOCK eseten a masodik
argumentumban lev} signalok ki lesznek veve a maszkolt signalok halmazabol, m g a
o
SIG SETMASK eseten a maszkolt signalok halmazat newset-re all tja az operacios rendszer, az addigi tartalmatol fuggetlenul. Ha a newset argumentum erteke NULL, akkor a
maszkolt signalok halmaza nem modosul. Ha az oldset argumentum erteke nem NULL,
akkor az altala kijelolt helyre az operacios rendszer eltarolja az eppen maszkolt signalok
halmazat.
A POSIX de nalja meg a sigpending() illetve a sigsuspend() rendszerh vasokat is:
ez el}bbivel egy folyamat lekerdezheti a szamara kuldott, de varakozo signalok halmazat
o
m g a sigsuspend() fuggvennyel a maszkolt signalok halmaza modos thato, majd az
operacios rendszer a folyamat futasat felfuggeszti addig, am g legkozelebb egy signalt
nem kap.

3.6 Meg egy kicsit a folyamatokrol
A kes}bbiekben bemutatott peldaprogramok (pl. majd a TCP alapu konkurrens szerver)
o
m}kodesenek megertesehez fontos tisztaban lenni azzal, hogy mi tortenik miutan egy
u
folyamat meghal (vegrehajtja az exit() rendszerh vast vagy kill signalt kuld onmaganak,
stb ...), hogy szerezhet err}l tudomast a szul} folyamat.
o
o
Egy szul}-folyamat egy gyermek-folyamat befejez}desere a wait() rendszerh vassal
o
o
varakozhat. Egyetlen parametere egy int t pusu objektumra mutato pointer, ahova (a
magasabb helyiertek} byteba) a meghalt gyermek exit-statusza kerul (ami 0 szokott lenni,
u
ha nem volt hiba egyebkent nem 0, de ez inkabb egy konvencio, aminek a betartasa nem
kotelez}) - ha a pointer nem NULL-pointer. Visszateresi erteke egyenl} a befejez}dott
o
o
o
gyermek-folyamat azonos tojaval (ha van ilyen). Ha a folyamatnak nincs egyetlen (futo
vagy befejez}dott) gyermeke, akkor a visszateresi erteke -1.
o
A kovetkez} esetek lehetsegesek miutan egy gyermek-folyamat vegrehajtotta az
o
exit() rendszerh vast, ami utan nincs visszaut:
A szul} folyamat mar vegrehajtott egy wait() rendszerh vast, es ekkor a rendszo
erh vas a fent eml tett modon visszater.
A szul} folyamat (meg) nem hajtott vegre wait()-et. Ekkor a gyermek-folyamatbol
o
zombie-processz lesz (err}l korabban mar volt szo). Ez azt jelenti, hogy minden
o
altala lefoglalt er}forras fel lesz szabad tva, kiveve a processz-tablabeli bejegyzes,
o
amiben az exit-statusz van tarolva (ennek az az oka, hogy nem lehet tudni azt,
hogy a szul} vegrehajt-e majd valamikor egy wait rendszerh vast ...)
o
Ha a folyamat azonos toja es folyamat-csoport azonos toja megegyezik, es a folyamat "login"-shell folyamat volt (azaz a terminal group azonos to 2.1 is egyenl}
o
a folyamat azonos tojaval), akkor akkor a folyamat-csoport minden tagja megkap
egy SIGHUP signalt. (Ezert halhatnak meg a hatterben futo folyamataink, ha
kijelentkezunk - es ezt a signalt ignoraltatja a nohup UNIX parancs a folyamattal.)
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A UNIX masik lehet}sege, hogy miutan egy folyamat egy exit() rendszerh vast
o
vegrehajtott, azutan egy SIGCLD (Signal the Death of a Child) signalt kuld
a szul}nek. Ez azert jo, mert a signal-handlerben le lehet kerdezni a meghalt
o
gyermek-folyamat exit-statuszat egy wait h vassal, gy elkerulhet} a zombieo
folyamatok veletlen elszaporodasa. (Csak az AT&T System V UNIX ad arra
lehet}seget, hogy a programnak ne is kelljen tor}dni a zombie-processzekkel. Ehhez
o
o
vegre kell hajtani a
signal(SIGCLD, SIG_IGN)

rendszerh vast. Ez azt eredmenyezi, hogy ezutan ha egy gyermek meghal, a UNIX
mag nem general a szul}nek SIGCLD signalt, a gyermek a zombie allapot kio
hagyasaval orokre feledesbe merul.)
Meg egy fontos dolog van, amin a UNIX kesz t}inek el kellett gondolkodniuk: mi
o
legyen akkor, ha a szul}-folyamat hal meg el}bb?
o
o
Ekkor a gyermekhez tarolt szul}-folyamat azonos to mez} ervenytelen folyamato
o
azonos tot tartalmaz! Ezt ugy oldottak meg, hogy bevezettek egy specialis (1-es
azonos toju) folyamatot, az init folyamatot (ez ind tja el a terminalokon a login: folyamatokat). Az "arva" gyermek-folyamatoknak ez lesz szul}-folyamatukkent tarolva. Ez
o
majd id}nkent gyeli, es megtiszt tja a "halott arva zombie" folyamatok altal lefoglalt
o
processztabala-bejegyzesekt}l a processz-tablat. (Az init folyamat sosem hajt vegre
o
exit() rendszerh vast.)

3.7 INPUT/OUTPUT eszkozoket vezerl} rendszo
erh vas
A UNIX rendszerben egyetlen I/O-vezerl} rendszerh vas van: az ioctl(), de ez a
o
kulonboz} periferiakon (karakteres specialis fajlokon) mas-mas dolgokat vegezhet (a
o
parametereit az adott periferiahoz tartozo device driver kapja meg es ugy ertelmezi,
ahogyan akarja). A PC-ken peldaul ez a rendszerh vas kapcsolhatja a keperny}t gra kus
o
megjelen tesi modba.
Egyetlen hasznalatat erdemes megnezni ennek a rendszerh vasnak: a terminal-modok
beall tasat.
A UNIX rendszerekben a terminal device driverje harom kulonfele modon m}kodhet:
u
raw, cbreak illetve cooked modban. A raw uzemmodban a terminalon (bilenty}zeten,
u
RS-232 vonalon, ...) beadott karakterek egyenkent at lesznek adva a felhasznaloi programnak, ekkor minden billenty} "egyenrangu", a specialis billenty}knek (pl. backspace,
u
u
CTRL-S, CTRL-Q stb.) ekkor nincs semmi hatasuk a programra. A cbreak modban a
karakterek szinten egyenkent lesznek a felhasznaloi programnak atadva, de a specialis billenty}ket ekkor az operacios rendszer "elkapja", feldolgozza, es ezeket nem adja tovabb
u
a felhasznaloi programnak. A specialis billenty}ket es hatasukak a kovetkez} tablazat
u
o
foglalja ossze (a lista nem teljes):
CTRL-S : A keperny}re rast fel kell fuggeszteni
o
CTRL-Q : A keperny}re rast folytatni kell (mivel CTRL-S-sel valamikor meg lett
o
all tva).
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CTRL-D : Fajlvege generalasa
DEL : SIGINT signal kuldese a futo programjainknak (ezt a program letilthatja).
CTRL-\ : SIGQUIT signal kuldese a futo programnak, hogy alljon le, es a memoria
tartalmat az operacios rendszer egy core nev} fajlba kimenti az aktualis directou
ryba. (Azaz egy core-dumpot kesz t rola az operacios rendszer, amit kes}bb egy
o
debuggerrel elemezni lehet ...).
A cooked modban az operacios rendszer sorvege- (vagy fajlvege-)jellel lezart egesz
sorokat olvas be a billenty}zetr}l, es a beolvasott sort egyben adja a a felhasznaloi
u o
programnak. A felhasznalo a backspace billenty}t hasznalhatja a beadott karakterek
u
torlesere, es a fent eml tett specialis funkcioju billenty}k is hatasosak.
u
A terminal-parameterek egy termio struktura t pusu valtozoba lekerdezhet}k az
o
operacios rendszert}l4 , es ha akarjuk, akkor ezt megvaltoztathatjuk, majd visszaado
hatjuk az operacios rendszernek, hogy all tsa be a bels} strukturait ennek megfelel}en.
o
o
A struktura szerkezete a kovetkez} (itt is a teljesseg igenye nelkul):
o
#define NCC ....
struct termio {
short c_iflag
short c_oflag
short c_cflag
short c_lflag
char c_line
short c_cc NCC]
}

Az egyes mez}kben a fent eml tett modokat, RS-232 terminalnal a baudrate erteket,
o
a karaktertorl} billenty} es mas specialis billenty}k kodjat lehet megadni, es meg sok-sok
o
u
u
mas dolgot (pl. az operacios rendszer vegezzen-e a beadott karaktereken CR-->LF konverziot vagy sem, { ez hasznos lehet peldaul terminal-emulator programok kesz tesenel,
de err}l most nem rok reszletesebben).
o
A terminalparametereket a
:::

ioctl(tfd, TCGETA, &tpars)

rendszerh vassal lehet lekerdezni egy tpars (struct termio t pusu) valtozoba (tfd a
terminalhoz kapcsolt fajl, lehet peldaul 0 is, ha a szabvanyos bemenet a terminalhoz van
kotve). A parametereket atall tani gy lehet:
ioctl(tfd, TCPUTA, &tpars)

RAW modba kapcsolashoz a kovetkez} parametereket kell atall tani:
o
4 A POSIX szabvanyban kicsit modosult a struktura szerkezete, es atneveztek termios nevre, de lenyeges
valtozasok nem tortentek { kenyelmi fuggvenyek bevezetesen es egy-ket uj terminalparameter bevezetesen k vul.
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/* ioctl ... */
oldlflag=lflag /* Elozo modot elmentem */
lflag=(lflag & ~(ECHO | ISIG | ICANON) /* Karaktervisszairast
(ECHO-t) is kikapcsolom */

Vissza az "el}z}" modba:
oo
lflag=oldlflag
/* ioctl ... */

(Megjegyzes: ezek a m}veletek egyes UNIX rendszerekben lehet, hogy mashogy menu
nek, esetleg mas mez}nevek vannak a termio strukturaban, ... ennek erdemes utananezni
o
mondjuk a "man termio" paranccsal. Ezeknek a beall tasara egyebkent letezik egy curses
nev} standard konyvtar is benne a raw(), cooked(), cbreak() fuggvenyekkel, amit ha
u
kell hasznalhatunk.)
A UNIX kernelnek azt a reszet nevezik line discipline modulnak, amely a teriminalinterfaceen bejov} karakterek feldolgozasat vegzi a fenti szempontok szerint.
o

3.8 Egyeb rendszerh vasok
Ebbe a csoportba azok a rendszerh vasok kerultek, amelyeket erdemes megismerni, de
a fent eml tett csoportok kozul egyikbe sem tartoznak olyan szorosan. Az itt ismertetend} rendszerh vasok a kovetkez}k: chmod(), chown(), chgrp(), getuid(), getgid(),
o
o
geteuid(), getegid(), setuid(), setgid() es a time().
A chmod() rendszerh vassal lehet beall tani (ill. atall tani) egy fajl vedelmi bitjeit.
Az els} parametere a fajl neve, a masodik parameter pedig a vedelmi bitek uj erteke. A
o
chown() rendszerh vassal lehet egy fajl tulajdonosanak az azonos tojat megvaltoztatni.
A rendszerh vas els} parametere a fajl neve, masodik parameter pedig az uj tulajdonos
o
felhasznaloi azonos toja. A harmadik parameter az uj tulajdonos csoport-azonos toja.
(Ezt a rendszerh vast csak a fajl "jelenlegi" tulajdonosa vagy a root (a szuperfelhasznalo)
hajthatja vegre.)
A getuid(), getgid() rendszerh vas a programot futtato felhasznalo azonos tojat
illetve csoport-azonos tojat adja vissza eredmenyul. A geteuid() ill. getegid() rendszerh vas hasonloan m}kodik, kiveve ha egy setuid bittel ellatott programban hajtjak
u
vegre. Ekkor annak az uid-jet ill. gid-jet adja vissza eredmenyul, akie a futtathato program volt (pontosabban: az e ektiv felhasznaloi azonos tot es csoport-azonos tot adja
vissza).
A setuid() es setgid() rendszerh vasokkal a folyamathoz tarolt felhasznaloi
azonos tot es csoport-azonos tot lehet atall tani. A szuperfelhasznalo (illetve az a
folyamat, amely setuid root modon lett elind tva) barmilyen felhasznaloi- es csoportazonos tora beall thatja a folyamathoz tarolt felhasznaloi- es csoport-azonos to ertekeket,
de ez visszafele nem megy. Egy "mezei" felhasznaloi folyamat nem tudja a tarolt
azonos tokat megvaltoztatni.
A time() rendszerh vasnak egy parametere van (de annak erteke NULL-pointer is
lehet). A rendszerh vas eredmenyul visszaadja az 1970 januar 1-e ota eltelt masodpercek
szamat. Ha a parameter nem NULL- pointer, akkor ezt az erteket be rja a parametere
altal mutatott memoriac mt}l.
o
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3.9 Egy osszetettebb pelda: a shell
Ebben a reszben egy minimalis kepesseg} shell (parancsertelmez}) funkcioit ellato prou
o
gram forraslistaja van. A programon keresztul a UNIX alapvet}bb rendszerh vasait iso
merhetjuk meg (ezert kerultem a szabvanyos I/O konyvtar hasznalatat, a printf()-et
es egyebeket).
A shell f}programja { a main() fuggvenynel ciklusban ki r egy prompti ($) karaktert
o
{ ezzel jelezve a felhasznalonak, hogy parancsra var { majd beolvas egy sort a szabvanyos
bemenetr}l (ami ugye leggyakrabban a billenty}zetr}li olvasast jelenti interakt v shello
u o
eknel).
Ezutan a beadott parancsot a darabol() nev} eljarassal szetszedi reszeire, az argstrs
u
nev} parametereben megadott tombot (a benne lev} mutatokat) a beadott parancs egyes
u
o
komponenseire all tja: az els} (azaz a nulla index}) elemet a vegrehajtando parancs
o
u
nevere all tja, a kovetkez} elemet a vegrehajtando parancs els} argumentumara all tja,
o
o
stb. Az egyes parancsneveket/argumentumokat terminalja a \0 karakterrel.
A szetdarabolas utan a f}programban szul egy gyermek-folyamatot, ami el}szor
o
o
ellen}rzi, hogy az utolso argumentumban a szabvanyos kimenetet akartak-e atirany tani,
o
es ha ugy talalja, hogy azt akartak (vagyis egy > karakterrel kezd}dik), akkor lezarja az
o
addig ervenyes szabvanyos kimenetet, es megnyit egy uj fajlt (ami a szabvanyos kimenet
helyen, az 1-es fajldeszkriptorral jon letre, mivel az a legels} szabad fajldeszkriptor { ne
o
felejtsuk el, hogy a 0-as fajldeszkriptoron a szabvanyos bemenetet nem bantottuk, nem
zartuk le, ezert a program ilyen szempontbol helyesen m}kodik). A gyermek-folyamat
u
ezutan vegrehajtja az execvp() rendszerh vassal a k vant programot.
A szul}-folyamat varakozik, am g a gyermeke befejez}dik, majd uj parancsot ker.
o
o
Megjegyezzuk, hogy a folyamatok hatterbeli elind thatosaga azt jelenti, hogy ezt a
varakozast (a wait() rendszerh vast) ki kellene hagyni, es a gyermek-folyamat halalat
jelz} signalt kellene kezelnie a shellunknek.
o
/* minsh.c
*
* Egy minimalis shell
* A szabvanyos bemenet (standard input) csatornarol olvas programneveket es
*
program-argumentumokat, es vegrehajtja a megadott programokat a megadott
*
argumentumokkal.
* A szabvanyos kimenet atiranyithato - elegge primitiven:
>fajlnev
*
metakarakterekkel ... mint az igazi shellekben, DE itt ez csak es
*
kizarolag az utolso argumentumban fordulhat elo, vagyis a parancssor
*
vegen.
*/
#include <fcntl.h>
#define
#define
#ifndef
#define
#endif

CBUFSIZE 1024 /* Parancsbuffer merete */
NR_ARGSTRS 32 /* Maximalis argumentumszam */
NULL
NULL ((void *)0)
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void darabol(pbuf,argstrs,argn)
char *pbuf
char **argstrs
int *argn
{
int pozicioszamlalo=0,pbufhossz
int local_argn

local_argn=0
pbufhossz=strlen(pbuf)
while (isspace(pbuf pozicioszamlalo]) && pozicioszamlalo<pbufhossz) {
pbuf pozicioszamlalo]='\0'
pozicioszamlalo++
}
while (pozicioszamlalo < pbufhossz) {
argstrs local_argn]= &pbuf pozicioszamlalo]
local_argn++
while (!(isspace(pbuf pozicioszamlalo])) && pozicioszamlalo<pbufhossz)
pozicioszamlalo++
while (isspace(pbuf pozicioszamlalo]) && pozicioszamlalo<pbufhossz) {
pbuf pozicioszamlalo]='\0'
pozicioszamlalo++
}
}
argstrs local_argn]=NULL
local_argn++
*argn=local_argn
}
void main(argc,argv,envp)
int argc
char **argv, **envp
{
int gy_status /* A befejezodott gyermekfolyamat allapotarol ad informaciot */
char parancsbuf CBUFSIZE]
char *argstrings NR_ARGSTRS]
int argnum,fn,nchars
char *stdoutfnev
do {
write(1,"$ ",2)
if ((nchars=read(0,parancsbuf,CBUFSIZE)) > 0) { /* -1 hiba, 0 fajlvege */
darabol(parancsbuf,argstrings,&argnum)
if (argnum > 1) { /* Ha megadtak valami (vegrehajtando-) fajlnevet */
if (fork() == 0) {
fn=1
if ((argnum > 2) && (argstrings argnum-2] 0]=='>')) {
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stdoutfnev=&(argstrings argnum-2] 1]) /* Ronda, de vilagos ... */
close(1) /* lezarja az ezelotti szabvanyos kimenet fajlt */
fn=creat(stdoutfnev,0744)
argstrings argnum-2]=NULL argnum=argnum-1
}
if (fn == 1)
execvp(argstrings 0],argstrings)
else
perror("Standard kimenet atiranyitasa sikertelen ")
perror("execvp nem sikerult ")
exit(-1) /* Hiba - execvp sikertelen */
} else {
wait(&gy_status) /* szulo var */
}
}
}
} while (nchars != 0)
if (nchars == (-1)) perror(" hiba a standard input olvasasakor ")
}

3.10 Daemon folyamatok
A UNIX operacios rendszerben vannak olyan feladatok, amiket a hatterben (gyakran
"eszrevetlenul") futo folyamatok vegeznek el. Ilyen peldaul a rendszeres feladatok futtatasat vegz} cron program. Ezeket a programokat daemon folyamatoknak is nevezik.
o
Mivel ezeket a folyamatokat nem a terminalrol ind tjak, altalaban a rendszerind taskor
automatikusan indulnak el, ezert nem illik a keperny}re rniuk (esetleg nagyon nagy
o
rendszerhibak eseten ezt azert megtehetik), es nem illik olyan er}forasokat fenntartaniuk,
o
amikre nincs szukseguk. Ahhoz, hogy egy daemon folyamat a feladatanak ellatasahoz
szukseges er}forrasokon k vul minel kevesebb mas er}forrast foglaljon le, kialak tottak
o
o
olyan konvenciokat, amiket a daemon folyamatokat rva kovetni erdemes. Ebben a pontban ezekr}l a konvenciokrol lesz szo, majd bemutatunk egy C kodreszletet, amely e kono
venciok alapjan lett meg rva, es felhasznalhatjuk sajat daemon folyamataink kesz tesekor.
Egy daemon folyamatnek el}szoris vegre kell hajtania egy fork() rendszerh vast,
o
majd a szul} reszenek egy exit()-et. Ezzel egyreszt a gyermek { a leend} daemon
o
o
{ nem lesz processz-csoport vezet}je, masreszt pedig mivel a szul} vegrehajt egy
o
o
exit() rendszerh vast, ezert a shell ugy tekintheti, hogy a daemont elind to parancs
befejez}dott (vagyis eredmenyul a daemon fut, de a shell promptot is visszakapjuk).
o
Vegre kell hajtani a setsid() rendszerh vast. Ezzel a folyamat egy uj processzcsoportot kepez, aminek } lesz a vezet}je, es a vezer} terminalt sem koti le a
o
o
o
tovabbiakban (vagyis a kijelentkezesunk utan ujabb bejelentkezes is tortenhet rajta).
A munka-directoryt all tsuk a gyokerre (/) vagy a /tmp-re. Ezzel a daemonunk
nem akadalyozza annak a fajlrendszernek az esetleges kiileszteset umount() rendszerh vassal, amely az elind tasakor aktualis munkadirectoryt tartalmazta.
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All tsuk a folyamat umask erteket nullara.
Zarjuk le a felesleges fajlokat.
A fenti lepeseket a kovetkez} eljaras megteszi:
o
int daemon_init(void)
{
int pid

close(0)
close(1)
close(2)
pid=fork()
if (pid < 0) return (-1)
if (pid != 0) exit(0) /* a szulo folyamat befejezi a futasat */
setsid()
chdir("/")
umask(0)
return(0)
}

3.11 POSIX-threadek
Igaz ugyan, hogy a "hagyomanyos" UNIX rendszerek (egy-ket kivetellel) nem biztos tanak lehet}seget tobb szalon futo (multi-threaded) alkalmazasok kesz tesere rendszo
erszolgaltatas szinten, de manapsag egyre tobbfele olyan C konyvtar kaphato (mind a
kommersz, mind pedig a szabad szoftver szferaban), amely lehet}ve teszi a UNIX folyamo
atok tovabbosztasat, tobbszalu futtatasat. Ebben a pontban err}l fogok reszletesebben
o
rni. Mivel a legtobb ilyen kiegesz t} konyvtar a POSIX thread szabvanyat koveti (ez
o
a POSIX 1003.4a), ezert en is ezt a szabvanyt fogom bemutatni. Megjegyzem, hogy a
POSIX thread-szabvanyanak csak egy reszet fogom ismertetni nem celom a szabvany
teljes kor} bemutatasa.
o

3.11.1 POSIX threadek letrehozasa es megsz}ntetese
u
Egy uj POSIX threadet (a tovabbiakban P-thread) a
hozhatunk letre. Ennek protot pusa a kovetkez}:
o
int pthread_create

pthread create()

fuggvennyel

(pthread_t *thread,
pthread_attr_t *attr,
pthread_func_t func,
any_t arg)

A pthread create() fuggveny letrehoz egy uj threadet az attr argumentumaban
megadott attributumokkal5 . A thread futasa a func argumentumban megadott
5

Thread attributum peldaul a thread szamara rendelkezesre allo vegrehajtasi verem merete.
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fuggvenynek, az arg argumentumban atadott ertekkel mint fuggvenyargumentummal
torten} vegrehajtasabol all (vagyis ez ugy viselkedik, mintha vegrehajtanank
o
parhuzamosan a func(attr) C nyelv} fuggvenyt ). Az els} argumentumban azt
u
o
a helyet kell megadni, ahova a thread-konyvtar az elind tott thread azonos tojat teheti.
Ha az elind tando thread attributumaival kapcsolatban nincsenek kulonosebb igenyeink,
akkor megadhatjuk az attr argumentumkent a pthread attr default erteket.
Miutan a thread befejezte a feladatat, vegre kell hajtania a pthread exit()
fuggvenyt. Ennek a fuggvenynek egyetlen argumentuma van, a befejez}dott thread
o
kilepesi kodja, amit a thread elind toja a thread befejezese utan megkap. Ennek a
fuggvenynek a protot pusa a kovetkez}:
o
:::

void pthread_exit(any_t status)

P-threadek varhatnak mas P-threadek befejez}desere a pthread join() fuggvennyel.
o
Ennek protot pusa a kovetkez}:
o
int pthread_join(pthread_t thread, any_t *exit_status)

A pthread join() fuggvenyt vegrehajto thread megvarja az els} argumentumaban
o
megadott thread befejez}deset, majd a masodik argumentumaban visszaadja a befeo
jez}dott thread kilepesi kodjat (amit a pthread exit() vegrehajtasakor a befejez}d}
o
oo
thread megadott).
Mivel a pthread join() fuggvenyt a mar befejez}dott P-threadekre vonatkozoan
o
is vegrehajthatjuk (es ez m}kodik is!), ezert a P-thread konyvtar kenytelen az osszes
u
elind tott threadr}l informaciokat nyilvantartani (peldaul a thread kilepesi kodjat). Aho
hoz, hogy a nyilvantartott informaciok ne foglaljak le a memoriat, a programozonak
lehet}sege van a pthread detach() fuggvennyel azt tanacsolnia a P-thread konyvtarnak,
o
hogy a fuggveny egyetlen argumentumaban speci kalt threadre vonatkozoan nem fogja
tobbe vegrehajtani a pthread join() fuggvenyt, ezert a megadott threadre vonatkozoan
nyilvantartott informaciokat a tovabbiakban nem kell tarolni. A protot pusa a kovetkez}:
o
int pthread_detach(pthread_t *thread)

3.11.2 POSIX threadek identitasa

A pthread self() fuggveny hasznalhato a thread identitasanak meghatarozasara. E
fuggveny visszateresi ertekekent megadja az }t vegrehajto thread thread-azonos tojat. A
o
fuggveny protot pusa a kovetkez}:
o
pthread_t pthread_self(void)

A
pthread t
t pusu
adatelemek egyenl}segvizsgalatara hasznalhato a pthread equal() fuggveny. Ket aro
gumentuma egy-egy P-threadet azonos tson, visszateresi erteke pedig csak akkor igaz,
ha az argumentumaiban megadott thread-azonos tok ugyanazt a threadet azonos tjak.
Ennak a fuggvenynek a protot pusa a kovetkez}:
o
int pthread_equal(pthread_t thread1, pthread_t thread2)
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3.11.3 POSIX threadek szinkronizacioja

A POSIX szabvany a threadek szinkronizaciojara ket alapvet} eszkozt biztos t: a muo
texeket es az }rfeltetel-valtozokat.
o
Miel}tt e ket szinkronizacios eszkozt megismernenk, megjegyezzuk, hogy mind a muo
texeket, mind pedig az }rfeltetel-valtozokat hasznalatuk el}tt inicializalni kell, amire a
o
o
kovetkez} fuggvenyeket hasznalhatjuk:
o
int pthread_mutex_init(pthread_mutex_t *mutex,
pthread_mutexattr_t *mattr)
int pthread_cond_init(pthread_cond_t *cond,
pthread_condattr_t *cattr)

Mindket fuggveny masodik argumentuma az adott szinkronizacios eszkoz jellemz}it
o
kell, hogy rogz tse (err}l reszletesebben a 3.11.4 pontban fogok rni).
o
Egy mutex altalaban a szabad es a foglalt allapotok valamelyikeben van, es a mutexeket ket m}velettel lehet manipulalni: a LOCK es az UNLOCK. A LOCK m}velet a szabad
u
u
mutexet foglaltra all tja, a foglalt mutexnel pedig addig varakozik a program, am g a
mutex szabadda nem valik, es azutan all tja foglaltra a mutexet. Az UNLOCK m}velet
u
a mutexet szabadra all tja. Megjegyezzuk, hogy mind a LOCK mind pedig az UNLOCK
m}veletnel le rtak atomi, oszthatatlan modon tortennek, ezert egy szabad mutexet ket
u
egymastol fuggetlen LOCK semmikeppen nem all that foglaltta: ilyenkor el}szor csak az
o
egyik LOCK lesz sikeres, majd miutan a sikeres LOCK-ot vegrehajto kiadja az UNLOCK-ot,
azutan fogja a masik (LOCK-ra varakozo) a mutex allapotat foglaltta modos tani. (A mutex lenyegeben egy binaris szemafor funkciojat valos tja meg a LOCK es az UNLOCK pedig
a Dijkstra-fele P/V szemaform}veleteket implementaljak.)
u
A LOCK m}velet a pthread mutex lock() fuggvennyel van implementalva, m g az UNLOCK
u
a pthread mutex unlock() fuggvennyel implementalhato. Ezeknek a protot pusa a
kovetkez}:
o
int pthread_mutex_lock(pthread_mutex_t *mutex)
int pthread_mutex_unlock(pthread_mutex_t *mutex)
int pthread_mutex_trylock(pthread_mutex_t *mutex)

A pthread mutex trylock() fuggveny lefoglalt (LOCK-olt allapotban lev}) mutex
o
megadasa eseten nem varakozik, mint a pthread mutex lock(), hanem -1 visszateresi
ertekkel azonnal visszater, es az errno valtozoban az EBUSY hibakod-konstanst helyezi
el. Ha szabad a mutex, akkor pedig vegrehajt rajta egy LOCK lefoglalasi m}veletet, es
u
ugy ter vissza.
Az }rfeltetel-valtozokat hosszabb varakozasok eseten erdemes hasznalni. A mutexo
eket csak rovid ideig tarto, threadek kozti kolcsonos kizaras megszervezesere hasznaljuk,
es egy mutexet foglalo threadet soha ne varakoztassuk meg hosszabb ideig (a gyakorlatban altalaban a mutexekkel egy-egy (konstans) ertekadas oszthatatlansagat szoktak biztos tani ugy, hogy az ertekadas ele beraknak egy LOCK, moge pedig egy UNLOCK m}veletet
u
egy, az ertekadas bal oldalan allo valtozot "ved}" mutexszel). Az }rfeltetel-valtozokat
o
o
altalaban a hosszabb idej} varakoztatasokra hasznaljak, amikor egeszen addig kell varni,
u
am g egy er}forras fel nem szabadul. Altalaban minden }rfeltetel-valtozohoz tartozik
o
o
egy mutex objektum is, aminek a hasznalatat az orfeltetel-valtozon ertelmezett ket
}
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alapm}velet bemutatasakor ismertetek. Az orfeltetel-valtozokon ket alapvet} m}velet
u
}
o u
van de nialva: a varakozas es a "szabad" jelzes kuldese az orfeltetel-valtozon varakozo
}
folyamat(ok) reszere.
Egy }rfeltetel-valtozon valo varakozas ugy van de nialva (es megvalos tva), hogy
o
UNLOCK-olja a hozza tartozo mutexet, es varakozik, am g az orfeltetel-valtozon egy masik
}
thread nem jelez "szabad" jelzest (es e ket m}velet "atomi", oszthatatlan modon hajtodik
u
vegre). Termeszetesen a varakozo m}velet h vasa el}tt a mutexet LOCK m}velettel at kell
u
o
u
all tani. Az }rfeltetel-valtozonal varakozasi m}velet protot pusa a kovetkez}:
o
u
o
int pthread_cond_wait(pthread_cond_t *cond,
pthread_mutex_t *mutex)

A m}velet els} argumentum annak az }rfeltetel-valtozonak a neve, amelyre
u
o
o
vonatkozoan kes}bb a "szabad" jelzest varjuk a masodik argumentum pedig a { h vas
o
el}tt { LOCK-olt mutexet adja meg. Ennek a fuggvenynek a hasznalatakor el}fordulhat
o
o
{ ha kis valosz n}seggel is {, hogy a visszateresekor az }rfeltetel-valtozo nincs "szabad"
u
o
allapotban, vagyis tovabb kell varni (ez akkor fordulhat el}, ha egy orfeltetel-valtozonal
o
}
egyidej}leg tobb thread varakozott, es a "szabad" jelzes utan el}szor utemezett thread
u
o
lefoglalja az er}forrast, a tobbi threadnek pedig ujra varakoznia kell). A fuggveny viso
szateresekor az garantalva van, hogy a mutex LOCK-olt allapotban van a visszateres
utan, gy az el}bb eml tett { "hamis szabad jelzes" { problemara megoldast jelenthet
o
e fuggvenynek a ciklusban valo vegrehajtasa addig, am g tenylegesen megszereztuk az
er}forrast.
o
A varakozasra vonatkozoan id}korlatot is lehet adni a pthread cond timedwait()
o
fuggvennyel (ilyenkor nincs garantalva, hogy az er}forras a megadott id}n belul felszo
o
abadul, csak az, hogy ez a fuggveny legkes}bb az adott id} mulva visszater).
o
o
Egy }rfeltetel-valtozora "szabad" jelzes kuldese a pthread cond signal() illetve a
o
o
pthread cond broadcast() fuggvennyel lehetseges. Ezek kozul az els} csak egy threadet
enged tovabbfutni, a masodik pedig az }rfeltetel-valtozon varakozo osszes threadet
o
tovabbengedi6. E ket fuggveny protot pusa a kovetkez}:
o
int pthread_cond_signal(pthread_cond_t *cond)
int pthread_cond_broadcast(pthread_cond_t *cond)

Mindket fuggveny egyetlen argumentuma az az }rfeltetel-valtozo, amelynel varakozo
o
folyamatok futasat tovabb akarjuk engedni. Az }rfeltetel-valtozok hasznalatara teko
intsuk a kovetkez} peldat { az els} programreszlet egy er}forrast lefoglalni szandekozo
o
o
o
threadb}l szarmazik, m g a masodik egy, az er}forrast eddig birtoklo, de a hasznalati
o
o
jogarol lemondani szandekozo thread altal lesz vegrehajtva.
pthread_mutex_lock(&mutex)
...
while (!szabad)
6 Vagyis ez okozhatja a fent eml tett "hamis szabad jelzes" problemat { ugyanakkor gondoljuk meg, hogy
egyes problemak megoldasa soran erre szukseg lehet, mivel peldaul egy adatbazis olvasasat egyszerre tobb
folyamat is vegezheti, rasat pedig legfeljebb egy, ezert ha egy, az adatbazist egyedul hasznalo ro folyamat munkajanak befejezese utan az osszes olvasot egyszerre akarjuk tovabbind tani (hiszen koztuk nem kell
kolcsonos kizarast biztos tani), akkor az osszes varakozo folyamatot tovabb kell engedni, es az egy masik
megoldando problema lesz, hogy ro folyamatokat ne engedjunk tovabb, csak az olvasokat (ha van olvaso).
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pthread_cond_wait(&cond, &mutex)
szabad=FALSE
pthread_mutex_unlock(&mutex)

Tekintsuk az er}forras hasznalati jogrol lemondani szandekozo threadb}l szarmazo
o
o
reszletet:
pthread_mutex_lock(&mutex)
szabad=TRUE
pthread_mutex_unlock(&mutex)
pthread_cond_signal(&cond)

Mind a mutexeknek mind pedig az }rfeltetel-valtozoknak megvannak a megszuntet}
o
o
m}veletei (destruktor m}veletek). Ezeknek a protot pusa a kovetkez}:
u
u
o
int pthread_mutex_destroy(pthread_mutex_t *mutex)
int pthread_cond_destroy(pthread_cond_t *cond)

3.11.4 Mutexek illetve }rfeltetel-valtozok attributuo
mai

Mind
a
mutexek,
mind
pedig az }rfeltetel-valtozok egyes jellemz}it letrehozasukkor rogz teni kell. Erre valo
o
o
a letrehozo pthread mutex init() illetve a pthread cond init() fuggvenyek masodik
argumentumaban megadhato (pontosabban megadando) attributum objektum { vannak
mutex attributum objektumok illetve }rfeltetel-valtozo attributum objektumok is (ezek
o
nem azonosak!).
Egy mutex attributum valtozot (t pusa pthread mutexattr t a C nyelven) a
pthread mutexattr init() fuggvennyel inicializalhatunk, amelynek egyetlen argumentuma az inicializalando mutex attributum objektum (memoriabeli c me). A fuggveny
protot pusa a kovetkez}:
o
int pthread_mutexattr_init(pthread_mutexattr_t *mattr)

Egy mutex attributum valtozot megszuntetni a
m}velettel lehet. Ennek protot pusa a kovetkez}:
u
o

pthread mutexattr destroy()

int pthread_mutexattr_destroy(pthread_mutexattr_t *mattr)

Az }rfeltetel-valtozo attributum objektumok letrehozasat illetve megszunteteset a
o
fentiekhez hasonlo funkcioju fuggvenyekkel vegezhetjuk el, melyeknek protot pusa a
kovetkez}:
o
int pthread_condattr_init(pthread_condattr_t *cattr)
int pthread_condattr_destroy(pthread_condattr_t *cattr)
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3.11.5 Konyvtarak thread-biztossaga

Az operacios rendszer fejleszt}i kornyezetehez tartozo konyvtarak gyakran hasznalnak
o
globalis valtozokat ugy, hogy a modos tasuk (illetve kiolvasasuk) nincs mutexekkel vedve
(a valtozo roi valamint olvasoi kozt nincs megvalos tva a megfelel} kolcsonos kizaras). Ez
o
sok problemat okozhat, aminek az a kovetkezmenye, hogy ezek a konyvtarak modos tas
nelkul nem hasznalhatoak tobb threadet alkalmazo programokban. Ezen lehet seg teni
un. thread-kopenyekkel, amik egy egyszer} szinkronizacios mechanizmust tamogatnak:
u
egyetlen kozos globalis mutexszel vedik a konyvtar fuggvenyeit ugy, hogy egyszerre legfeljebb egy fuggveny lehet akt v. Ezt a szinkronizacios mechanizmust ugy meg lehet
valos tani, hogy minden fuggveny torzse ele el kell helyezni egy, a globalis mutexre
vonatkozo LOCK m}veletet, valamint a torzs vegere egy ugyanarra a mutexre vonatkozo
u
UNLOCK m}veletet.
u
Gondoskodni kell meg a mutex inicializalasarol, amit egy, a program elejen
megh vando segedfuggvennyel oldhatunk meg.
Vagyis az eredeti konyvtar egy fuggvenye a kovetkez}keppen modosul (ha "tiszto
esseges" programot akarunk rni, akkor gondoskodni kell ennek a mutexnek a deallokalasarol is { ehhez meg kell rni ugyanitt egy eljarast, amit peldaul a f}programunk
o
vegen megh vhatunk):
...
static int kell_inic=TRUE
static pthread_mutex_t mutex
static pthread_mutexattr_t mattr
...
fv_nevxxx(...)
{
pthread_mutex_lock(&mutex)
fv_nevxxx_EREDETI_TORZSE /* Ide jon a fuggveny eredeti torzse */
pthread_mutex_unlock(&mutex)
}
...
fv_init()
{
pthread_mutexattr_init(&mattr)
pthread_mutex_init(&mutex)
}

A thread-ekkel kapcsolatban problemat okozhat az, ha egy rendszerh vas blokkol
(peldaul egy read() m}velet addig blokkol, am g nincs meg a szukseges mennyiseg}
u
u
input adat. Ezt a megfelel} fajldeszkriptor nem-blokkolora all tasaval lehet kikuszobolni
o
(persze ezzel a programunkat kicsit bonyolultabb lesz meg rni, de lehet}ve valik az I/O
o
parhuzamossa tetele, ami miatt a thread-eket gyakran hasznaljak).
Egy fd fajldeszkriptorra vonatkozo m}veleteket egy folyamaton belul a kovetkez}
u
o
fuggvenyh vassal tehetjuk nem-blokkolova:
fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_NONBLOCK)
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Vagyis ezutan az fd fajldeszkriptorra vonatkozo I/O m}veletek csak annyi adatot
u
rnak olvasnak be/ rnak ki, amennyinek "hely van", vagyis amennyit varakozas nelkul ki
tudnak rni, majd visszaternek (altalaban visszaadva azt, hogy mennyi adatot sikerult
ki rni). Egy fajldeszkriptorra vonatkozo m}veletek blokkolora visszaall tasa a kovetkez}
u
o
fuggvenyh vassal vegezhet} el:
o
fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) & ~O_NONBLOCK)

3.11.6 Folyamatok kommunikacioja a UNIX-ban

A UNIX operacios rendszernek tobb elterjedt valtozata is van: egyik valtozata az AT&T
ill. Novell UNIX valtozata (a System V Release 4), a masik lenyeges valtozata a Berkeley
UNIX (peldaul a 4.3BSD). Vannak mas UNIX-szer} rendszerek is, mint peldaul a Linux,
u
amelyr}l itt nem rok reszletesebben, mert { legalabbis szamunkra { nincs lenyeges elteres
o
az "igazi" UNIX rendszerek es a Linux kozott.
A UNIX rendszerek nem tekinthet}k osztott rendszereknek, bar a UNIX halozati
o
lehet}segei nagyon sokret}ek. A transzparencia (peldaul a kommunikacio transzo
u
parenciajanak) hianya talan a legf}bb oka annak, hogy a UNIX rendszert altalaban nem
o
tekintik osztott operacios rendszernek. A UNIX sokfele kommunikacios eszkozzel rendelkezik:
Az SVR4 UNIX tartalmazza a szemaforokat, uzenetcsatornakat, osztott
memoriat mint kommunikacios eszkozoket, amelyek a Columbus UNIX-ban lettek kifejlesztve (a UNIX egy kutatasi valtozataban), es a System V UNIX-nak szabvanyos resze a BSD UNIX-nak ezek az eszkozok sokaig nem voltak reszei, vagyis
az ezeket az eszkozoket alkalmazo programokat nehezebb volt atvinni a nem System
V szarmazek UNIX rendszerekre. Ezeknek az eszkozoknek fontos jellemz}je, hogy
o
barki hozzaferhet, aki a hozzajuk tartozo un. globalis egyedi kulcsot (unique
key) ismerik. Letezik olyan rendszerszolgaltatas, amely letrehoz egy uj kommunikacios eszkozt (barmelyiket a harom kozul) egy megadott egyedi kulccsal { ha
az adott egyedi kulcshoz meg nem hoztak letre a kommunikacios eszkozt, akkor a
rendszer azt letrehozza, egyebkent pedig a rendszer hibauzenetet ad. Tovabba van
olyan m}velet, amely egy mar letrehozott kommunikacios eszkozhoz (egyedi kulcsa
u
alapjan) hozzaferesi lehet}seget ad a folyamatnak. Termeszetesen vannak olyan
o
m}veletek, amelyekkel a kommunikacios eszkozon a kommunikaciot vegzhetjuk.
u
A Berkeley UNIX kommunikacios eszkoze a socket rendszer. A socket lenyegeben
egy kommunikacios vegpont absztrakcioja, a kommunikacio pedig ezeknek az
osszekapcsolasan kerezztul folyhat. Minden socket resze valamely kommunikacios
domain-nek: altalaban annak, hogy programok kommunikalhassanak, szukseges
feltetele, hogy a kommunikaciot letes t} (osszekapcsolt) socketok azonos domainbe
o
tartozzanak. Minden sockethoz tartozik egy c m (ez a c m lehet egy Internetbeli IP
c m vagy egy DECnet c m { vagy akar egy fajlnev { attol fugg}en, hogy a socket
o
Internet, DECnet, vagy UNIX domainben lett letrehozva). Tovabba minden sockethoz tartozik egy karakter-sorozat, amely a kommunikacio soran elkuldott, de meg
nem feldolgozott (beolvasott) adatokat tarolja. A socket rendszerben lehet}seg van
o
socketok letrehozasara, sockethoz c m hozzarendelesere, ket azonos domainben lev}
o
socket osszekapcsolasara, es lehet}seg van osszekapcsolt socketok kozt adatatvitelre.
o
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A 4.4BSD UNIX kernelje jeleneg tartalmazza a TCP/IP, az X.25, a Xerox Network
System es az OSI TP4 es az OSI CLNP protokollcsaladok implementaciojat, es az
ezekhez valo hozzaferest a socket interfeszen keresztul teszi lehet}ve.
o
A Berkeley socket rendszer az AT&T TLI-jehez kepest (ld. ezt lejjebb) egyszer}bb,
u
kisse hianyos programozoi interfesz a halozati szolgaltatasokhoz, ugyanis tervezesekor meg nem voltak kikristalyosodva a transzport szolgaltatoktol szelesebb
korben elvart szolgaltatasok es egyes szolgaltatasok absztrakcioja sem volt igazan
sikeres (ezzel kapcsolatban gyakran eml tik a surg}s adattal kapcsolatban bizo
tos tott szolgaltatasok kulonboz}segeit is, amit azonban a transzport-protokollok
o
surg}s adat fogalmanak de n ciojanak kulonboz}segei okozzak). A Berkeley socket
o
o
rendszer nehany hianyossagara a TLI-r}l szolo pont vegen fogok utalni.
o
Az AT&T UNIX System V Release 3.0 reszekent lett ismert a TLI (Transport Layer Interface) mint egy interfesz reteg az OSI referenciamodell transzport retegenek szolgaltatasaihoz (a szerkezete, felep tese sokmindenben az
ISO Transzport Szolgaltatasanak De n ciojan alapszik). Terminologiajaban a
TLI a kommunikacios vegpontot (ami altalaban egy processz) transzport
vegpontnak nevezi, az operacios rendszer altal a felhasznaloi programoknak
nyujtott halozati transzport-protokoll szolgaltatasok implementaciojat pedig transzport szolgaltatonak nevezi. M g a Berkeley socket rendszer a BSD UNIXban rendszerh vasokkent erhet} el, addig a TLI egy konyvtar, amely kapcsolao
tot teremt a transzport szolgaltato es a transzportvegpont kozott (a transzport
szolgaltato altalaban STREAMS device driverek es a rajuk epul} STREAMS
o
modulok formajaban van a kernelben implementalva), tehat a TLI nem egy
transzport-protokoll implementacio. Az AT&T UNIX System V Release 4.0ig (SVR4) a UNIX AT&T valtozata nem tartalmazott transzport szolgaltatot, majd
a SVR4-ben megjelent a DARPA Internet TCP/IP protokollcsaladjanak egy implementacioja transzport szolgaltatokent.
A Berkeley socket interfesz az ISO Transzport Szolgaltatasanak De n ciojanal
korabban szuletett, gy az ISO Transzport Szolgaltatasainak egyes reszei a Berkeley
socket rendszeren keresztul nem elerhet}k:
o
{ A Berkeley socket rendszer nem teszi lehet}ve az ISO Transzport Protokoll
o
De n cioban szerepl} kapcsolatfelvetel elutas tast: egy kapcsolat automatikuo
san felepul miel}tt a felhasznaloi program barmit is megtudhatna a kommuo
nikacios partnerr}l, es csak ezutan van lehet}seg a kapcsolat lebontasara,
o
o
amir}l azonban a kommunikacios partner tudomast szerezhet (de egyes
o
szolgaltatasoknal ezt illene "titkosan" kezelni).
{ A Berkeley socket rendszerben nincs lehet}seg alkalmazasoknak transzporto
protokolltol fuggetlen elkesz tesere: altalaban nincs lehet}seg a hasznalando
o
transzport-protokoll futasid}beni (hordozhato modon torten}) kivalasztasara,
o
o
vagy legalabbis a rendelkezesre allo lehet}segek sokkal rugalmatlanabbak a
o
TLI-nyujtotta lehet}segeknel.
o
{ A Berkeley socket rendszer nem teszi lehet}ve kapcsolatfelvetelkori illetve
o
kapcsolatlezaraskori adatok atvitelet, m g a TLI erre lehet}seget nyujt.
o
A TLI ezen k vul biztos tja a Network Selection Facility nev alatt osszefoglalt
lehet}segeivel azt, hogy a programokat transzport-protokoll fuggetlen modon
o
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lehessen elkesz teni, leford tani, es a hasznalando transzport-protokollt csak a program futtatasakor kell speci kalni bizonyos UNIX kornyezetvaltozokban. A programok a transzport szolgaltato egyes parametereit a futasid}ben lekerdezhetik
o
es ezzel lehet}seguk van7 alkalmazkodni a helyi transzport szolgaltatohoz (azaz a
o
transzport-protokoll egyes jellemz}it, peldaul azt, hogy biztos tja-e a surg}s adat
o
o
tovabb tasat vagy sem, biztos t-e lehet}seget kapcsolatfelvetelkori adatcserere vagy
o
sem, )
:::

A UNIX a fenti alapvet} kommunikacios eszkozoket nyujtja az alkalmazasoknak. Erre
o
szamos alkalmazast ep tettek, mint peldaul a folyamatok tavoli elind tasat lehet}ve tev}
o
o
rsh alkalmazast (ez az un. tavoli shell szolgaltatas), a tavoli terminal szolgaltatast
nyujto rlogin illetve telnet alkalmazast, a halozati fajlrendszert: az NFS-t. Lehet}seg
o
van tavoli eljarash vas vegzesere is (peldaul a Sun Microsystems altal ingyen barkinek a
rendelkezesere bocsatott RPC es XDR szoftver-csomagokkal), amelynek a lenyege az,
hogy a halozati interfeszhez (peldaul a socket rendszerhez) a karakter-sorozat atvitelre
epul} kapcsolati modell helyett egy eljaras-h vasi kapcsolati modellt biztos t a proo
gramozonak: azaz a programozo a halozatban elosztott8 alkalmazas-komponensek kozti
kommunikaciot nem a komponensek kozt letrehozott adatcsatornakent latja, hanem a
tavoli eljarash vasi szoftver a szokasos eljarash vasok formajaban teszi lehet}ve az alkao
lmazas-komponensek kommunikaciojanak megszervezeset, es ezzel leveszi a programozo
vallarol az alacsonyszint} kommunikacios adatcsatorna kezelesenek gondjait (altalaban
u
az RPC-szoftverek az eljaras-fejek speci kacioja alapjan legeneraljak az alacsonyszint}
u
kommunikacios adatcsatorna kezeleset vegz} eljarasokat).
o
A UNIX operacios rendszerben szamos mas eszkozt megtalalhatunk egyuttm}kod}
u o
folyamatok kommunikaciojanak megoldasara: minden UNIX rendszerben megtalalhato
kommunikacios eszkoz a pipe. Ez lenyegeben egy egyiranyu adatcsatorna, mely
kizarolag kozos }st}l szarmazo folyamatok kozt johet letre (egy pipe vegen nem kell
o o
feltetlenul kulonboz} folyamatoknak lenni { egy pipenak akar mindket veget is kezelheti
o
egy folyamat (ezzel peldaul megoldhato adatok atmentese egy exec() rendszerh vast
kovet}en az ujonnan elind tott alkalmazas reszere). Megjegyezzuk, hogy a UNIX mai
o
valtozataiban (pl. System V Release 4, 4.4BSD) a pipe mar ketiranyu (full-duplex)
kapcsolatot biztos that a folyamatok kozt, de meg tovabbra is lenyeges korlatozas az
alkalmazhatosagaval kapcsolatban az, hogy a kommunikalni szandekozo folyamatoknak egy kozos }st}l kell szarmazniuk. Erre a problemara a nevvel ellatott pipe-ok
o o
nyujthatnak megoldast: ekkor ugyanis a hagyomanyos pipe-oktol elter}en a kommuo
nikacios csatorna vegeihez a kommunikalni k vano felek nem egy, a processzre nezve
lokalis, csak leszarmazottak fele orokolhet} fajldeszkriptoron keresztul ferhetnek hozza,
o
hanem a kommunikacios csatorna vegpontjaihoz hozza lehet rendelni egy fajlrendszerbeli
nevet, amit az osszes folyamat elerhet fuggetlenul attol, hogy van-e kozos }suk vagy nincs
o
(itt a fajlrendszerben hasznalatos rwx-bitek seg tsegevel korlatozhato a kommunikalo
partnerek kore). Fontos megeml teni, hogy mind a pipe mind pedig a nevvel ellatott
pipe a UNIX fajlrendszer szokasos m}veleteivel kezelhet} (tobbek kozt read() illetve
u
o
write() rendszerh vasok seg tsegevel).
7 Ez alatt azt kell erteni, hogy akkor van lehet}seg a helyi transzport szolgaltatohoz valo alkalmazkodasra,
o
ha a programot olyanra rtak, hogy alkalmazkodni tudjon a helyi transzport szolgaltatohoz.
8 Az elosztott fogalmat itt nem a korabban mar bemutatott osztott rendszer osztottsaganak ertelmeben
hasznalom, hanem egyszer}en az alkalmazas szetdarabolasat ertem ezalatt.
u
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3.12 Kerdesek
1. Probaljuk ki, hogy mit r ki a kovetkez} program! (Miert erdekes ez?)
o
#include <stdio.h>
main()
{
int fd1,fd2
char c
fd1=creat("/tmp/tfil1",0770)
write(fd1,"alma",4)
close(fd1)
fd1=open("/tmp/tfil1",0)
fd2=dup(fd1)
read(fd1,&c,1)
printf("%c",c)
read(fd2,&c,1)
printf("%c",c)
close(fd2)
close(fd1)
}

2. Az fstat rendszerh vas nem folosleges? Minden esetben lehet a stat rendszerh vassal "helyettes teni"?
3. Mit csinal a kovetkez} program? (Tegyuk fel, hogy a C ford tonk nem vegez optio
malizaciot.)
#include <signal.h>
int i
elj1()
{
i=23
}
main()
{
printf("START!\n")
signal(SIGINT,elj1)
i=0
while (i==0) {
kill(getpid(),SIGINT)
}
printf("STOP!\n")
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}

4. B}v tsuk a shellunket tovabbi UNIX shell metakarakterekkel! (Peldaul a >>, &, <,
o
stb...)
5. B}v tsuk a shellunket shell-valtozok kezelesenek lehet}segevel.
o
o
6. B}v tsuk a shellunket egyszer}bb vezerlesi szerkezetekkel.
o
u
7. B}v tsuk a shellunket a pipe lehet}seggel. Gondoljuk meg, hogy a pipe-ba kapcsolt
o
o
folyamatokat milyen sorrendben kell/erdemes elind tani ahhoz, hogy a szokasos
UNIX shellekben megismert modon m}kodjenek.
u
8. Jellemezzuk es hasonl tsuk ossze egymassal a threadek szinkronizaciojara
hasznalatos eszkozoket!
9. Kesz tsunk el egy thread-biztos B-fa konyvtarat: egy olyan B-fa adatszerkezetet
kezel} konyvtarat, amelynek az eljarasai egyszerre tobb threadb}l h vhatoak, es
o
o
probaljunk meg minel nomabb szinkronizacios mechanizmust beep teni, azaz
probaljunk meg minel magasabb foku parhuzamossagot megengedni.
10. A thread-ekr}l szolo reszben ismertetett thread-kopeny mechanizmus illetve impleo
mentacio milyen esetekben nem megfelel} (milyen esetben okozhat holtpontot)?
o

Fejezet 4
Halozatok
A halozat altalaban tobb egymashoz kapcsolt szam togepb}l all, amelyek kozott lehet}seg
o
o
van informaciocserere es er}forrasmegosztasra. A halozatba kapcsolt gepeket hostoknak
o
nevezik, es minden ilyen hostnak van egy egyedi azonos toja (es ezzel egyutt egy egyedi
c me). Szokas megkulonboztetni a helyi halozatokat (LAN- okat), es a nagytavolsagu
halozatokat (WAN-okat). A LAN-ok atviteli sebessege tobb megabit/sec., m g a
WAN-oke gyakran csak 9600 bit/sec. Az internet (vagy internetwork) tobb ilyen
egymassal osszekapcsolt LAN-bol illetve WAN-bol all (es ez nemcsak az INTERNETre
vonatkozik).
A szam togepek kozotti kommunikacio szigoru szabalyok (protokollok) szerint zajlik, es mivel ezek a protokollok nagyon osszetettek, ezert un. logikai szintekre osztottak
o
}ket azert, hogy konnyebben lehessen }ket kezelni es implementalni. Egy lehetseges szo
intfelosztas a kovetkez}: zikai kapcsolat szintje, adatkapcsolati szint, halozati
o
szint es a transzport szint.
A zikai szint speci kalja a zikai adatatviteli kozeg parametereit: peldaul azt, hogy
mekkora lehet az osszekapcsolt gepek kozt kifesz tett drot maximalis hossza, mekkora
feszultseg jelenti a logikai 1-et illetve a logikai 0-at, stb.
Az adatkapcsolati szint speci kalja peldaul az ellen}rz}oszeg kiszam tasi modjat, az
o o
atviend} bitfolyam feldarabolasanak (az un. keretkepzes) szabalyait es meg sok mas
o
dolgot. Ez es a zikai szint egyertelm}en meghatarozzak az egymassal zikailag (peldaul
u
drottal) osszekapcsolt szam togepek kozott lezajlo kommunikacio szabalyait.
A halozati szint feladata annak a megoldasa, hogy a kommunikacio ne csak az
egymassal kozvetlen kapcsolatban lev} gepek kozott folyhasson, hanem ket tetsz}leges
o
o
halozatba kapcsolt host kozott is, ezert a halozati reteg (illetve a halozati protokoll) feladata a csomagoknak a forrashosttol a celhostig torten} elirany tasa, az utvonalkijeloles
o
(routing).
A transzport szint feladata az, hogy adatokat fogadjon a felette lev} szoftvero
retegt}l, kisebb darabokra vagja szet azokat es tovabb tsa a halozati reteg fele. Majd
o
a celallomason az ottani transzport szint feladata lesz az egyes csomagoknak az eredeti
sorrendbe rendezese. A legtobb hoston egyszerre tobb folyamat is futhat, ezert szukseg
lehet tobb transzport-kapcsolatnak a halozati retegre torten} a multiplexelesere (illetve
o
demultiplexelesere). Ennek a megoldasa is a transzport szintre tartozik.
Egyes szabvanyok ezeken k vul mas szinteket is de nialnak, az OSI peldaul a
viszonyszintet, amely a tobb fel kozott kialakult kapcsolat szinkronizalasara szolgal
az adatabrazolasi szintet, amely peldaul a halozaton keresztulhalado adatok bels}
o
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abrazolasanak, titkos tasanak es tomor tesenek modjaval foglalkozik. Ez azert is fontos,
mert az un. host byte order gyakran elter a network byte ordert}l. (A network
o
byte order { a halozati bytesorrendre vonatkozo szabvany { a Motorola proceszorok bels}
o
abrazolasi formajaval egyezik meg, es nem az Intelevel! A reprezentacios problemak
azoknal a gepeknel is el}jonnek, ahol egy byte nem 8, hanem esetleg 9 vagy 10 bitet
o
tartalmaz (ilyen is van ...). Ezert a legtobb halozati terminologiaban a bitnel "szelesebb"
adategysegkent nem a byteot, hanem az oktettet hasznaljak, ami mindenkeppen 8 bitb}l
o
all, es az egyes hostok feladata a "helyi" byte<-->oktett transzformacio megoldasa.)
Fontos, hogy ezek a protokollok azt nem speci kaljak, hogy a programok ezeket a
szolgaltatasokat hogyan, milyen programozoi interfeszen keresztul vehetik igenybe.
Ez altalaban nagyon operacios rendszert}l fugg} dolog: a UNIX rendszerekben ilyen
o
o
interfeszek a Berkeley socket interface es a TLI (Transport Layer Interface, szabvanyos tott valtozatanak neve XTI). A BSD UNIX nagy elterjedtsege miatt talan a
socket interfesz az elterjedtebb. Az AT&T UNIX alatt is letezik socket interfeszt biztos to
rendszerkonyvtar.
A kommunikacio altalaban ugy megy, hogy a felhasznaloi program atadja az atviend}
o
adatokat a transzport-szintnek, az feldarabolja az adatokat kisebb csomagokra, kiegesz ti
egy transzport-fejleccel, es ezt atadja a halozati szintnek. A halozati szint tovabbi
szukseges fejlecekkel egesz ti ki azt, es tovabbadja az alatta lev} szintnek, s. .t. Az
o
adatok rendeltetesi helyen pedig ugyanez tortenik, csak ford tott iranyban.

4.1 A halozati kapcsolat modellje
A halozati kapcsolat ketfele lehet: osszakottetes-alapu vagy osszekottetes-mentes.
sszekottetes-alapu kapcsolat eseten egy "virtualis csatorna" keletkezik a kommunikalo
felek kozott, amely ved az adatismetlest}l illetve adatvesztest}l. Osszekottetes-mentes
o
o
kapcsolat eseten a kommunikacio un. datagramok kozvet tesevel zajlik, senki sem
garantalja azt, hogy egy elkuldott datagram megerkezik a celjaba, sem pedig azt, hogy ha
az elkuldott datagramok megerkeznek, akkor csak egy peldanyban illetve csak az elkuldes
sorrendjeben erkezhetnek meg.
A kommunikacio altalaban nem szimmetrikus: az egyik, a kezdemenyez} fel (a kliens)
o
a masik felt}l (szervert}l) valamilyen szolgaltatast ker. A halozati kommunikacio lego
o
gyakrabban erre az un. kliens-szerver modellre epul.
Egy szerver szerkezete altalaban ketfele lehet: iterativ vagy parhuzamos (ezt
nevezik konkurrensnek is). Az iterativ szerver ugy m}kodik, hogy ciklusban fogadja,
u
es kieleg ti a hozzakapcsolodott kliensek igenyeit. A konkurrens szerver minden egyes
kliensevel valo kapcsolattartashoz szul egy gyermek-folyamatot, ami a kliens altal igenyelt
szolgaltatasokat elvegzi - majd altalaban leall.

4.2 A TCP/IP protokollcsalad
A mai egyik legnagyobb halozat a DARPA Internet, amely a 70-es evek vegen ill. a
80-as evek elejen keszult el. A DARPA Internetbe kapcsolt gepek egy un. TCP/IP
protokollcsalad seg tsegevel kommunikalnak egymassal.
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4.2.1 A zikai es az adatkapcsolati szint

Ebben a protokollcsaladban a zikai es az adatkapcsolati szintet egy un. Ethernet
halozati csatlakozo biztos tja. A hostok kozott vegigmegy egy kabel, es ez az Ethernet egy un. CSMA/CD (Carrier Sense Multipla Access with Collision Detect) technikaval biztos tja azt, hogy egyszerre csak egyvalaki hasznalja ezt a kabelt, illetve ha
ezt nem sikerul elernie, akkor az egymassal "utkoz}" adokat veletlen ideig varakoztatja,
o
majd megprobalhatnak ujraadni. Minden egyes Ethernet csatlakozo-nak van egy 48bites egyedi c me, es minden egyes Ethernet csatlakozo csak azokat az csomagokat veszi
le a kabelr}l, amelynek } a c mzettje (vagy az uzenet egy un. broadcast uzenet volt,
o
o
amit mindenkinek meg kell kapnia). Egy host akar tobb Ethernet csatlakozoval is rendelkezhet, amelyek mas-mas LAN-okon vannak (multihomed host). Ekkor ez a host
kepes lesz routing-feladatokat is ellatni: peldaul az egyik halozatrol uzeneteket atkuldeni
a masikra, ha szukseges (az ilyen hostokat gateway gepeknek is nevezik).
Megjegyzes: A TCP/IP protokollok fels}bb szintjei nagymertekben kihasznaljak azt,
o
hogy alattuk egy "uzenetszorasos" (azaz broadcast-re is kepes tudo) halozati csatlakozo
van, de megoldottnak tekinthet} a TCP/IP protokolloknak soros (mondjuk egy szo
abvanyos RS-232) vonalon keresztuli hasznalata (az IBM PC-ken a TCP/IP megy ArcNET halozati interface felett is).
Tovabbi megjegyzes: roviden ismertetem nehany halozati csatlakozo eszkoz
adatatviteli sebesseget (mivel nincs mindegyikr}l reszletes informaciom, ezert a
o
reszletesebb ismertetest}l inkabb eltekintek). Ethernet kabelkent (az epuletet behalozo
o
gerincvezetekkent) napjainkban ketfele technologiat hasznalnak: egyreszt a vekony Ethernet kabelt, masreszt a vastag Ethernet kabelt. Mind a vekony mind pedig a vastag
Ethernet kabeleken megvalos thato egy 10 Mbit/sec sebesseg} adatatvitel (a ma (1996u
ban ...) legelterjedtebb halozati kabelek ugy tudom, hogy meg inkabb a vekony Ethernet
kabelek). A vastag Ethernet kabeleket alkalmazvamegfelel} (nagy sorozatban is elerhet})
o
o
Ethernet kartyaval 100 Mbit/sec sebesseg} adatatvitelt lehet megvalos tani. Helyi
u
halozatok osszekapcsolasara egy kezenfekv} zikai retegbeli atviteli kozeg a telefonvonal
o
(modemeken keresztul). Ezeken ma a digitalis telefonkozpontokon jol hasznalhatoak a
14400 bit/sec sebesseg} atvitel megvalos tasara kepes modemek, esetleg a 28800 bit/sec
u
sebesseg} modemek (m g a gyenge nem digitalis telefonkozpontokon { ugy tudom {, hogy
u
a 2800-9600 bit/sec atviteli sebesseg az igazan elterjedt). Magyarorszagon ugy tudom
nem hasznaljak, de Amerikaban egyre inkabb terjednek az un. T1-es telefonvonalak a
transzkontinentalis T1 vonalakon joval nagyobb adatatviteli sebessegek erhet}k el: kb.
o
1.5 Mbit/sec.

4.2.2 A halozati szint (IP)

A TCP/IP halozati szint} protokollja az Internet Protocol (ez az IP), ez vegzi az
u
csomagoknak a forrashosttol celhostig irany tasat. Minden egyes hostnak (pontosabban
minden egyes Ethernet vagy mas halozati csatlakozonak) van egy un. Internet c me (IPc me), ami lenyegeben egy 4-byteos szam, es a 4 byteot pontokkal elvalasztva decimalisan
szokas megadni. Ez a c m teljesen fuggetlen az Ethernet-c mekt}l, es ugy lett kialak tva,
o
hogy az utvonalkijelol} algoritmust a lehet} legegyszer}bben lehessen megoldani. Az IPo
o
u
c m ket reszb}l all: egy net-idb}l es egy host-idb}l. A net-id azonos tja az Internetben
o
o
o
az egesz LAN-t, m g a host-id a LAN-on belul a hostot azonos tja. Aszerint, hogy a 4
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bytebol mekkora resz a host-id es mekkora a net-id szokas megkulonboztetni A, B es C
osztalyu IP- c meket a kovetkez}keppen:
o

Class:A
Class:B
Class:C

0 2 4 6 8
........|........|........|........
0 net-id|
host-id
10
net-id
|
host-id
11
net-id
| host-id

-adik bit

Mivel a csupa 0 es a csupa 1 host-id broadcast m}veletek szamara van fenntartva,
u
ezert egy C osztalyu helyi halozatban maximum254 host lehet bekotve. (A hostokat nemcsak a fenti 4-byteos c mekkel lehet azonos tani, hanem szoktak nekik mas - konnyebben
megjegyezhet} - neveket is adni (peldaul kutya vagy macska vagy tehen vagy valami mas
o
emberibbnek nevezett nevet). Ekkor a halozatban kell lennie egy (vagy tobb) ugynevezett
nameserver gepnek, amely az "emberibb" hostnevet 4-byteos Internet c mme alak tja
(mivel az operacios rendszer belul csak ezt a format hasznalja). Ezt a hostnev --> IPc m transzformaciot barmelyik programunkban elvegeztethetjuk az operacios rendszerrel
- erre a kes}bbiekben meg visszaterunk. (A fent eml tett neveket domain neveknek is
o
szoktak nevezni.)
Megjegyezzuk, hogy a halozatba kapcsolt komponensek nevekkel valo ellatasa
az Internetben szepen meg van oldva host szinten (vagyis az egyes hostokat,
azok halozati interfeszeit el tudjuk latni egy-egy nevvel), de a meglev} nevo
semaba nem igazan illeszthet}k be mas halozati er}forrasok, es nincs lehet}seg
o
o
o
absztrakt halozati objektumok letrehozasara (ilyen objektum lehetnek peldaul a
felhasznaloi csoportok, vagy akar felmerulhet az egyes gepeken futo folyamatok
c mezhet}segenek a kerdese is). Ezeknek a problemaknak { ugy t}nik { egy jobb
o
u
megoldasat k nalja a CCITT X.500 szabvanya: itt abbol indulnak ki, hogy minden objektumnak vannak bizonyos attributumai, es az objektum azonos tasakor
az attributumait kell megadni (peldaul ilyen tekintetben az ullman.inf.elte.hu
szam togep csb es c nev} felhasznaloi altal alkotott admin nev} csoportjara az
u
u

/ORSZAG=hu/INTEZMENY=elte/SZERVEGYSEG=informatika/SZERVER=ullman/CSOPORT=admin

modon
hivatkozhatnank,
magara
a
szam togepre
pedig az /ORSZAG=hu/INTEZMENY=elte/SZERVEGYSEG=informatika/SZERVER=ullman
modon hivatkozhatnank. Ennek a modszernek az a szepsege, hogy mindenfajta objektumot be tudunk illeszteni ebbe a jelolesrendszerbe (pontosabban: le rasrendszerbe).
Az IP-routing kisse leegyszer}s tve a kovetkez}keppen megy: adott egy forras-IPu
o
c m es egy cel-IP-c m. Ha a ket c m net-id resze megegyezik, akkor a ket allomas egy
halozaton van (ha nincsenek un. subnetek ... mert ha vannak, akkor a host-idb}l meg
o
nehany bit a net-idhez lesz kapcsolva, es ugy lesz az egyenl}seg vizsgalva), es ekkor az
o
un. ARP protokollal a kuld} allomas meghatarozza a celallomas IP- c me alapjan ano
nak az Ethernet-kartya c met, es oda kuldi a csomagot. Ha a ket net-id kulonbozik,
akkor a forrashostbol a halozatba kapcsolt un. default gatewaynek lesz elkuldve a
csomag, aki majd biztosan tovabb tani tudja a rendeltetesi c mre. Az ARP-s routingot
direkt, m g az utobbi default gatewayeset indirekt routingnak nevezik. (Az INTERNET halozat kozpontjaban van egy ugynevezett Core Gateway System, amely nagyobb

4.2. A TCP/IP PROTOKOLLCSALAD

75

kapacitasu gateway gepekb}l all, amelyekben a routingot mas gatewayek kozotti proo
tokollokkal es algoritmusokkal kiegesz tve is vegzhetik.) Az IP-routing egy specialis
lehet}sege az un. source routing, az IP-csomag kuld}je altal torten} utvonalkijeloles:
o
o
o
ilyenkor az IP-csomagot kiegesz tik olyan opciokkal, amiben fel van sorolva az, hogy
az IP-csomagot milyen routereken keresztul milyen sorrendben merre kell a cel-c mehez
tovabb tani (vagyis ekkor az utvonalkijeloles nem a default gateway ismeretei alapjan
tortenik).
Az IP-routingot kisse megnehez tik a mobil szam togepek elterjedese. Ennek a
problemanak a megoldasara fejlesztettek ki az MIP (Mobile IP Extension) protokollt.
Eszerint minden egyes mobil szam togepnek van egy allando IP-c me, ez alapjan egy
"anya-halozata" (ez az allando IP-c menek a net-id resze alapjan meghatarozhato) de
egy mobil szam togep nem csak az "anya-halozaton" keresztul kapcsolodhat az Internetre,
hanem barmelyik un. IAP-n (Internet Access Point, Internet Hozzaferesi Pont) keresztul
(egy mobil szam togep terbeli mozgasaval { "vandorlasaval" { termeszetesen valtozhat az
az IAP, amelyen keresztul belep az Internetbe). A MIP protokoll lenyegeben arra epul,
hogy az "anya-halozat" routerei ismerik a mobil gepek aktualis IAP-jeit, gy a mobil
gepeknek kuldott IP-csomagokat tudjak tovabb tani nekik az IAP-n keresztul az IP protokoll source-routing lehet}segenek seg tsegevel. Termeszetesen a mobil gepekr}l kuldott
o
o
csomagok tovabb thatok az IAP-fele mint default router fele, es onnan a "hagyomanyos"
IP-routing seg tsegevel eljuttathatoak a rendeltetesi helyukre.
Az ARP protokoll a kovetkez}: k vancsiak vagyunk egy adott IP- c m} gep Ethero
u
net c mere. Ehhez ugy kell egy ARP-csomagot kikuldeni, hogy azt miden egyes rendszer
megkapja (broadcast seg tsegevel). Minden egyes host, amely egy ARP csomagot beolvas a halozatrol beolvas, ellen}rzi, hogy nem az } IP-c me van-e benne, arra k vancsio
o
e az ARP csomag kuld}je. Ha az van benne, akkor kikuld egy valasz-csomagot a
o
kerdez}nek, amely tartalmazza az Ethernet-c met - ez megoldhato, mivel nyilvan a sajat
o
Ethernet c met minden egyes host le tudja valahogyan kerdezni.
Soros vonalon az Internet Protokoll egy specialis valtozatat, az SLIP-t (Serial Line Internet Protocol) hasznaljak. Az ilyen jelleg} hardver eszkozok nem tamogatjak az ARP-t
u
(nem is lenne sok ertelme, mert egy drotnak csak ket vege van), ezert az operacios rendszerbe az SLIP-kapcsolatok vegpontjairol az informaciokat "kezzel" kell bekon guralni
(vagyis azt, hogy melyik soros vonalon milyen IP-c m} host erhet} el).
u
o
Nyilvanos halozatokban gyakran hasznalt halozati protokoll az X25.

4.2.3 A transzport szint

A TCP/IP protokollcsalad ket transzport-szint} protokollja a TCP (Transmission Conu
trol Protocol) es az UDP (User Datagram Protocol). A TCP oszekottetes-alapu, m g
az UDP nem az.

Az UDP protokoll
Az UDP altal nyujtott szolgaltatasok lenyegeben megegyeznek az IP altal biztos tott
szolgaltatasokkal. Egy lenyeges b}v tes az IP-hez kepest az, hogy az UDP tobb komo
munikacios portot (TSAP-ot, Transport Service Access Point-ot) biztos t, ahonnan ill.
ahova csomagokat lehet kuldeni, es ha egy program UDP-n keresztul akar kommunikalni
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masokkal, akkor az UDP csomagok elkuldesekor meg kell adni a cel-host IP-c me mellett annak az ottani UDP-portnak a sorszamat, ahova a csomagot kuldeni akarja (az
UDP fejlec tartalmazza annak a helyi UDP-portnak a sorszamat is, ahonnan a csomagot
kuldtek, gy a celallomas azt kiolvasva tudja, hogy honnan kuldtek a csomagot, es ez
alapjan tudhatja, hogy hova kuldjon egy esetleges valaszt). Ezzel { marmint az UDP
portokkal { lehet}seg van egy hoston egyszerre tobb UDP-kapcsolat letrehozasara is, es
o
nincsenek olyan megkotesek, hogy egy folyamat egyszerre csak egy darab UDP kapcsolatot letes thet (mert az UDP-portok azonos toi es a folyamatok azonos toi egymastol
teljesen fuggetlenek).
Az UDP fejresz a kovetkez} mez}kb}l all:
o o o
|------------------------------------------------------|
|
Forras-port
|
Cel-port
|
|------------------------------------------------------|
|
Csomaghossz
|
Ellenorzo-osszeg
|
|------------------------------------------------------|
|
|
|
Felhasznaloi adatok
|
|
|
.
...
.
|
|
|------------------------------------------------------|

Az ellen}rz} osszeg szam tasa a kovetkez}keppen tortenik: 2-byteos szavankent kell
o o
o
osszeadni az UDP fejreszt, az IP pszeudo-fejreszt, es az elkuldend} adatokat, majd az
o
osszeg 1-es komplemenset kell kepezni. Az eml tett IP pszeudo-fejresz itt a forras ill.
cel-hoszt IP c meb}l, valamint a forras/cel UDP-port sorszambol all.
o

A TCP protokoll
A TCP a protokollcsaladnak talan a leggyakrabban hasznalt kommunikacios transzportprotokollja. (FONTOS: A TCP egy protokoll, es nem a kommunikaciot
megvalos to program!) Ha TCP protokollal kuldunk egy byte-folyamot (tetsz}leges
o
adatokat), akkor a TCP azt maximum64 byteos darabokra bontja, es ezeket a darabokat
egyenkent atadja az IP-nek (termeszetesen a TCP fejleccel ellatva), hogy kuldje el a rendeltetesi helyere. Az IP nem garantalja azt, hogy a csomagok a celallomasnal meg is
erkeznek, ezert a TCP feladata az, hogy adott esetben (pl. egy bizonyos id} lejartaval)
o
az egyes csomagokat ujra elkuldje, mivel lehet, hogy az el}z} peldany elveszett valaoo
hol. A celallomason a megerkezett csomagok sorrendje nem biztos, hogy az elkuldes
sorrendjevel megegyezik, ezert a TCP feladata ennek a rendezese is (ha szukseges). A
TCP termeszetesen a csomagduplazas ellen is vedelmet nyujt.
A TCP protokoll a megb zhatosagot az un. PAR (Positive Acknowledgement with
Retransmission) technikaval biztos tja. Ez azt jelenti, hogy a celallomas TCP-t megvalos to szoftvere nyugtazza a csomag kezbes teset, miutan a halozati szintt}l (az IP-t}l)
o
o
megkapta.
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Egy hoston egyszerre tobb TCP kapcsolat is elhet, es itt is, mint az UDP-nel az egyes
kapcsolatok kulon-kulon TCP-porton (TSAP-on) vannak. A TCP-kapcsolatok fullduplexek, vagyis ketiranyuak, es az elkuldott adatokat a TCP strukturalatlan bytefolyamnak tekinti. A TCP-vel ezen k vul lehet}seg van surg}s adatok tovabb tasara
o
o
is. A protokoll el} rja, hogy ha surg}s adatot kuldtunk, akkor az adat fogadojat a celo
o
hoston err}l ertes teni kell, es meg kell adni a lehet}seget a surg}s adat soron k vuli
o
o
o
feldolgozasara is. Az ertes tes modja (mivel oprendszer-fugg}) nincs a protokoll altal
o
speci kalva.
A TCP fejresz a kovetkez} mez}kb}l all:
o o o
|------------------------------------------------------|
|
Forras-port
|
Cel-port
|
|------------------------------------------------------|
|
Byte-sorszam
|
|------------------------------------------------------|
|
Nyugta
|
|------------------------------------------------------|
| TCP fejreszhossz| |URG|ACK|EOM|RST|SYN|FIN| Ablak |
|------------------------------------------------------|
| Ellenorzo osszeg
| Surgos adatok offsetje |
|------------------------------------------------------|
|
|
|
|
.
Felhasznaloi adatok
.
.
.
|
|
|------------------------------------------------------|

(A rajzon a TCP fejresz v zszintes merete 32 bit.)
A TCP portok 0-tol 1023-ig un. foglalt portok. Ezeknek a kiosztasi jogat a DARPA
fenntartja maganak. Peldaul a tavoli bejelentkezes (TELNET) protokoll szervere mindig
a 23-as TCP porton var arra, hogy valaki rakapcsolodjon es bejelentkezzen rajta az adott
hostra. Az altalaban jellemz}, hogy a fontosabb, szelesebb korben hasznalt protokollok
o
egy "mindenki altal ismert" (well-known) sorszamu port-on varnak kapcsolatokra.
A TCP fejresz bitjei a kovetkez}k:
o
URG: Ennek a bitnek 1 az erteke, ha a surg}s adatok o setje fejreszmez} ki van
o
o
toltve (es ervenyes ...). Ez az o set azt mutatja majd meg, hogy az aktualisan
atvitt byte utan hanyadik byte utan kovetkezik a surg}s adat.
o
SYN: Oszekottetes-felep teskor fontos
ACK: "Nyugta" mez} ervenyes adattal van-e kitoltve
o
FIN: A kuld}nek nincs tobb elkuldend} adata (ezzel zarul le az egyik iranyban a
o
o
kapcsolat).
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RST: Inkonzisztens allapotba kerult osszekottetes megszuntetesere vonatkozo
kerelem.
EOM: End Of Message ag (nem kell a TCP kapcsolat hasznalojatol adatokra
varni (am g a 64 byteos szokasos TCP uzenethossz osszejonne), mert rovid id}n
o
belul lehet, hogy nem lesz uj elkuldend} adat). Ez peldaul a TELNET protokollnal
o
hasznos. Milyen ciki lenne, ha a terminalon beadott karaktereket a terminalunk
csak 64 byte beadasa utan kuldene el a tavoli hosztra, ahova bejelentkeztunk.
Az ellen}rz} osszeg szam tasa a kovetkez}keppen megy: 2-byteos szavankent kell
o o
o
osszeadni a TCP fejreszt, az IP pszeudo-fejreszt, es az elkuldend} adatokat, majd az
o
osszeg 1-es komplemenset kell kepezni. A byte sorszam megmondja, hogy az egesz
atkuldend} adatfolyambol most epp hanyadik byteot kuldjuk at (a TCP uzenet els}
o
o
bytejanak az adatfolyamon beluli sorszama). A nyugta mez} megmondja, hogy a komo
munikacios partner az elkuldend} adatfolyamunknak hanyadik bytejat varja (es ez nem
o
lehet es nem is lesz monoton csokken}!). A TCP ellen}rz} osszegnel eml tett IP pszeudoo
o o
fejresz a forras ill. cel-hoszt IP c meb}l, valamint egyeb protokoll-informaciokbol es az
o
aktualis TCP uzenet hosszabol all. (A byte sorszam kezd}erteke nem minden kapcsolat
o
eseten nulla - a kezdeti erteket a kapcsolat letrehozasakor a ket partner egyezteti.)

4.3 TCP/IP kon guracio
Minden egyes szam togep operacios rendszere biztos t valamilyen lehet}seget a TCP/IP
o
halozati reteg alapvet} parametereinek (pl. a host IP c me, neve, ) a beall tasara.
o
A legtobb rendszerben a Berkeley UNIX-bol szarmazo segedprogramok hasznalhatoak
ilyen celra, de sok helyen kesz tettek olyan interaktiv segedprogramokat is, amelyek interaktivan megkerdezik a felhasznalot/rendszergazdat a szukseges informaciorol,
majd vegrehajtjak a Berkeley UNIX-bol szarmazo segedrutinokat a megfelel} felo
parameterezessel.
Megjegyezzuk, hogy az alabb lathato peldak egyes szam togepeken maskent
m}kodhetnek lehet, hogy mas szam togepen mas formaban adjak ki az eredmenyuket.
u
Ennek oka az egyes operacios rendszerek segedprogramjainak a minimalis kulonboz}sege
o
lehet. Ha ilyen jelleg} problemakkal talalkozunk, akkor nezzuk meg a megfelel} parancu
o
sok referencia kezikonyvbeli le rasukat a parancs pontos m}kodeser}l: altalaban a ki rt
u
o
angol szovegek megfogalmazasa mas- es mas lehet, de a lenyeges informaciok (pl. a gep
IP-c me, Ethernet c me) minden esetben ki rasra kerul.
:::

4.3.1 Halozati csatlakozok

Egy szam togep { mint mar eml tettuk { egyszerre tobb halozati csatlakozoval is el lehet
latva. Ezeknek a csatlakozoknak a neveit a netstat parancs -i argumentummal torten}
o
vegrehajtasaval tudhatjuk meg. Erre tekintsuk a kovetkez} peldat:
o
Name
lo
eth0

MTU
2000
1500

RX-OK RX-ERR RX-DRP RX-OVR
0
0
0
0
0
0
0
0

TX-OK TX-ERR TX-DRP TX-OVR Flags
886
2
0
0 BLRU
0
1
0
0 BRU
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A halozati csatlakozok neveit az els} oszlopbol tudhatjuk meg a tobbi oszlop a
o
kovetkez} informaciokkal szolgal:
o
MTU : A csatlakozon elkuldhet} adat maximalis merete (a csatlakozo miatt
o
hasznalando Ethernet vagy mas fejlecek nelkul).
RX-OK : A csatlakozon fogadott hibatlan csomagok szama.
RX-ERR : A csatlakozon fogadott hibas csomagok szama.
RX-DRP : A csatlakozon erkezett, de valamilyen oknal fogva nem feldolgozott
csomagok szama.
RX-OVR : A csatlakozon erkezett, de a TCP/IP szoftver lassusaga miatt nem
fogadott szoftver.
TX-OK : A csatlakozon elkuldott hibatlan csomagok szama.
TX-ERR : A csatlakozon elkuldott hibas csomagok szama.
TX-DRP : A csatlakozora kuldott , de valamilyen oknal fogva eldobott csomagok
szama.
TX-OVR : A csatlakozon valamilyen oknal fogva nem elkuldoptt csoamgok szama.
Flags : A csatlakozo allapotat, jellemz}i rja le.
o

4.3.2 IP c m beall tasa

Egy halozati csatlakozo IP-c menek a beall tasat az ifconfig UNIX paranccsal
vegezhetjuk. Ha a szam togepunk ket halozati csatlakozoval van felszerelve: az egyik
a loopback (neve: lo) csatlakozo, amely a ra kuldott csomagokat egyszer}en visszajutu
tatja a helyi szam togepre (ezzel a helyi hostot c mzi meg), a masik pedig egy Ethernet
halozati kartya (neve: eth0), akkor azok IP-c meit a kovetkez} parancsokkal all thatjuk
o
be:
$ /etc/ifconfig lo 127.0.0.1
$ /etc/ifconfig eth0 157.181.52.1

A peldaban a loopback csatlakozohoz a 127.0.0.1, az Ethernet csatlakozohoz pedig
a 157.181.52.1 c met rendeltuk.
A szam togepunk egyes halozati csatlakozoihoz rendelt IP-c meket szinten az
ifconfig paranccsal kerdezhetjuk le. Erre tekintsuk a kovetkez} peldat:
o
$ ifconfig
lo
Link encap Local Loopback
inet addr 127.0.0.1 Bcast 127.255.255.255 Mask 255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1
eth0

Link encap 10Mbps Ethernet HWaddr 00:43:23:76:34:47
inet addr 157.181.53.43 Bcast 157.181.33.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
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Itt lathato a szam togep mindket halozati csatlakozojanak a rovid jellemzese: IP-c me,
a reszhalozaton broadcast celokra hasznalhato IP-c m, valamint a network mask konstans
erteke, amely a halozati interfesz IP-c meb}l kijeloli azt, hogy mely bitek tartoznak a
o
korabban mar eml tett net-id-hez (halozat azonos to). A net-id-et az IP-c m megfelel}
o
bytejainak a mask megfelel} bytejaival bitenkenti VAGY kapcsolatba hozassal kaphatjuk
o
meg. Az eth0 csatlakozonk net-id-je tehat a kovetkez}: 157.181.53.0.
o

4.3.3 ARP es RARP protokollok

A csomagok Internetbeli utvonalkijelolesehez hasznalt ARP protokoll implementaciojahoz az arp parancs seg tsegevel ferhetunk hozza. Az arp -a parancs ki rja
a rendszer ARP protokoll tablazatanak a tartalat (ez a tablazat szolgal az ARP-vel szerzett informaciok id}leges cache-elesere). Hasznalatara tekintsuk a kovetkez} peldat:
o
o
$ arp -a
Address
157.181.52.1
157.181.52.2

HW type
HW address
10Mbps Ethernet 00:80:73:41:65:56
10Mbps Ethernet 00:80:73:41:65:57

A fentiekb}l leolvashato, hogy annak a gepnek, amelyen az arp -a parancsot
o
vegrehajtottak, ket masik szam togeppel van { allando jelleg} { kapcsolata, leolvashato
u
ezek IP c me, halozati csatlakozojuk t pusa, Ethernet kartya c mei.
Az arp paranccsal megtudhatjuk akar egy-egy host Ethernet c met is az IPc me alapjan a host nevet mint argumentumot megadva. Az ullman.inf.elte.hu
szam togepen kiadva a kovetkez} parancsot, megkaphatjuk a tomx.inf.elte.hu
o
szam togep Ethernet c met:
$ arp tomx.inf.elte.hu
tomx.inf.elte.hu (157.181.52.2) is on 10Mbps Ethernet 00:80:73:41:65:57

Ebb}l megtudhattuk, hogy a tomx.inf.elte.hu szam togep Ethernet kartyajanak a
o
c me 00:80:73:41:65:57.
A ford tott iranyu (Ethernet c m --> IP c m) c mtranszformaciot az RARP protokollal
vegezhetjuk (ezt peldaul X-terminalok hasznaljak IP c muk meghatarozasara, ha csak
az Ethernet c muket ismerik: az Ethernet c muket a halozaton egy RARP csomagban
broadcast-elik (mindenkinek elkuldik), es minden egyes hoston az ott futo rarpd demon
kikeresi az Ethernet c m alapjan a host IP-c met, es visszakuldi az informaciot az RARP-t
kezdemenyez} X-terminalnak).
o
Az rarpd program a /etc/ethers fajlt hasznalja az IP-c mek meghatarozasara,
melynek formatuma a kovetkez}: soronkent tartalmaz egy Ethernet c met es egy IPo
c met (hostnevet is tartalmazhat, amely esetben a nameserver seg tsegevel lesz az adott
hostnev IP-c mme transzformalva). Tekintsuk a kovetkez} peldat a /etc/ethers fajlra:
o
00:80:73:41:34:34 ncd92.inf.elte.hu
00:81:7b:1e:65:23 ncd93.inf.elte.hu
00:80:73:41:8a:44 157.181.52.99
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4.3.4 Routing tablak
4.4 Kerdesek, feladatok
1.
2.
3.
4.
5.
6.
7.

Mi a halozatok zikai, adatkapcsolati, halozati es transzport szintjenek a feladata?
Mit ertunk osszekottetes-alapu kapcsolaton?
Milyen szerkezet} szervereket ismer?
u
Mi a kulonbseg a TCP es az UDP kozott?
Mi az ARP protokoll szerepe? Hogyan m}kodik?
u
Hogyan tortenik az IP-routing?
Mi az oktett?
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Fejezet 5
A Berkeley socketok
A socketok a UNIX-ban a halozati (es helyi ...) kommunikacio vegpontjai, ezeken
keresztul lehet a helyi transzport- es mas halozati retegekhez hozzaferni. Lenyegeben
postaladakent viselkednek: hozzajuk rendelhetunk bizonyos c meket, es fogadhatjuk roluk
az oda erkezett adatokat, illetve adatokat kuldhetunk el onnan masoknak. A socketokat
eredetileg a BSD UNIX-ban kesz tettek el, es az }ket manipulalo eljarasok ott rendo
szerh vasokkent erhet}ek el, de kes}bb az AT&T UNIX-hoz is kesz tettek egy socketo
o
emulacios konyvtarat, amely az AT&T kernel mas lehet}segeire epul.
o
A socket konyvtarak lehet}ve teszi halozati szoftverek kesz teset ugy, hogy a proo
gram kesz tese soran nem a program alatt lev} protokoll lehet}segeire kell a gyelmet
o
o
osszpontos tani. A socketok letrehozasakor meg kell adni azt, hogy a socket milyen kommunikacios domainbe tartozik (peldaul TCP/IP Internet vagy X25). Kes}bb ha majd a
o
sockethoz "c met" rendelunk, akkor a c met az adott domain-nek megfelel} formatumban
o
kell az operacios rendszerrel kozolni. Ezen k vul meg kell adni a kommunikacio modjat
is (pl. osszekottetes alapu byte-folyam jelleg} vagy datagram jelleg} ...). Ez alapjan a
u
u
rendszer kivalasztja az adott domain-en belul azt a kommunikacios protokollt, amely az
adott modu kommunikacio megvalos tasara kepes. Ha tobb protokollt is ismer a rendszer, amely a (domain,mod) parnak megfelel, akkor explicit modon meg lehet adni azt,
hogy azok kozul melyiket akarom hasznalni (ha ez elter a rendszerben ismert default
ertekt}l). Peldaul ha az Internet domain-en belul byte-folyam jelleg} kommunikaciot
o
u
akarok vegezni, akkor a rendszer automatikusan a TCP protokollt valasztja ki, mert
az Internet domain-en belul ez az alapertelmezes szerinti (bytefolyam-jelleg} kommuu
nikacio eseten). Ha az Internet domain-en belul datagram jelleg} kommunikaciot akarok,
u
akkor a rendszer az UDP-t valasztja ki, mert az Internet domain-en belul mindig az
az alapertelmezes szerinti protokoll datagram jelleg} kommunikacio eseten (arr}l meg
u
o
lesz szo reszletesebben, hogy mikor mi az alapertelmezes szerinti protokoll ...). Ezutan
a program visszakap egy egesz t pusu un. socket-le rot, amivel a socketra hivatkozhat.
Amennyire ez lehetseges, a socketok ugy viselkednek, mint a fajlok, tehat ha van ertelme,
akkor meg vannak rajuk engedve a szokasos read, write, close, ... fajlm}veletek.
u
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5.1 Egy osszekottetes-alapu kliens-szerver kapcsolat
menete
Az jellemz}, hogy egy kliens illetve szerver osszekottetes-alapu kommunikacio
o
letrehozasakor milyen rendszerh vasokat hasznal. Ezt foglalja ossze a kovetkez} ket
o
tablazat:
Egy kliens a kovetkez} rendszerh vasokkal kommunikalhat a szerverrel:
o
Socket letrehozasa
Socket c menek kijelolese
Kapcsolatfelvetel a szerverrel
Adatatvitel

socket()
bind()
connect()
write(), read()
send(), recv()
Adatatvitel befejezese (EOF) shutdown()
Socket lezarasa
close()
Egy szerver a kovetkez} rendszerh vasokkal kommunikalhat a kliensekkel:
o
Socket letrehozasa
Socket c menek kijelolese
Kliensekre varas allapotba kerules
Kliens kapcsolatkerelmenek elfogadasa
Adatatvitel
Adatatvitel befejezese (EOF)
Socket lezarasa

socket()
bind()
listen()
accept()
write(), read()
send(), recv()
shutdown()
close()

5.2 Egy nem osszekottetes-alapu kliens-szerver kapcsolat menete
Az jellemz}, hogy egy kliens illetve szerver nem osszekottetesalapu ( osszekotteteso
mentes) kommunikacio letrehozasakor milyen rendszerh vasokat hasznal. Ezt foglalja
ossze a kovetkez} tablazat:
o
Egy kliens es szerver kozti kommunikacio a kovetkez} rendszerh vasokkal folyhat le:
o
:::

Socket letrehozasa
Socket c menek kijelolese
Adatatvitel
Adatatvitel befejezese (EOF)
Socket lezarasa

socket()
bind()
sendto(), recvfrom()
shutdown()
close()
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5.3 Socketok c mzese az Internet domainben
Az Internet domain socketjaihoz tartozo c mek formatumat a kovetkez} struktura szerint
o
kell megadni az operacios rendszernek (deklaralva a <netinet/in.h> header leban van):
struct in_addr {
unsigned long s_addr
}

/* 4 byteos IP cim */

struct sockaddr_in {
short sin_family /* =AF_INET */
unsigned short sin_port /* 16 bites port-sorszam */
struct in_addr sin_addr /* IP cim */
char sin_zero 8] /* Kihasznalatlan */
}

o
A sin family mez} tartalmazza a c m t pusat (AF INET = Address Family in the
Internet Domain). A sin port tartalmazza a TCP vagy az UDP port sorszamot (aszerint, hogy a socket milyen t pusu: TCP vagy UDP). A sin addr mez} tartalmazza a
o
megc mzett objektum IP c met. Ez utobbi ket mez}t az un. halozati abrazolasi formaban
o
kell megadni (ld. kes}bb a htons, ill. htonl fuggvenyeket).
o

5.4 Konverzio a halozati- es host byte-abrazolasmod
kozott
A halozatba kapcsolt hostok kozott van olyan, amelyik a ketbyteos egeszeket ugy
tarolja a memoriaban (ez a host byte order, vagyis a memoriabeli tarolas formatuma),
hogy az alacsonyabb helyiertek} byteot a kisebb sorszamu memoriac men, a magasabb
u
helyiertek} byteot pedig a nagyobbik sorszamu memoriac men. Vannak olyan hostok is,
u
amelyeknel ez pont ford tva van, es ezert de nialtak egy un. network byte ordert, amely
a Motorola bels} tarolasi formatumanak felel meg, es a halozati portokat, es c meket
o
ilyen network byte orderben kell megadni a rendszernek. Ehhez azonban a host byte
orderr}l konvertalni kell az adatokat a network byte orderre.
o
Negy konverzios rutin van, amelyet hasznalhatunk:
htons

: host byte order --> network byte order (16 bites adat)

ntohs

: network byte order --> host byte order (16 bites adat)

htonl

: host byte order --> network byte order (32 bites adat)

ntohl

: network byte order --> host byte order (32 bites adat)

(Ha numerikus (egesz) adatokat viszunk at ket host kozott, akkor is hasznos (es
szukseges) ez a konverzio, ha hordozhato programot akarunk kesz teni.)
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5.5 Kommunikacios vegpont (socket) letrehozasa
Egy socketot a socket() rendszerh vassal lehet letrehozni. Ennek a rendszerh vasnak
harom parametere van: a c mformatum (domain neve), a socket t pusa es a hasznalando
kommunikacios protokoll. A socket rendszerh vas formatuma a kovetkez}:
o
sd=socket(address_family,socket_type,socket_protocol)

A kovetkez} tablazatban nehany domain-nevet lehet latni (a UNIX C header- leokban
o
ezek mint numerikus ertek} makrok vannak deklaralva):
u
Address family
AF INET
AF DECNET
AF NS
AF UNIX

Le ras
Internet domain
DecNET domain
Xerox Network System domain
Lokalis hoszton beluli IPC

A socket t pusan a socket "min}seget" kell megadni. Ennek ertekei a kovetkez}k
o
o
lehetnek:
Socket type
Le ras
SOCK DGRAM
Datagrammok tovabb tasat tamogato socket.
osszekottetesmentes kapcsolat kialak tasara alkalmas
nem garantal megb zhatosagot.
SOCK STREAM
Megb zhato, osszekottetes-alapu, byte-folyam jelleg} adatatvitelt tamogat.
u
Az elkuldott csomagok "egybefolynak".
SOCK SEQPACKET Megb zhato, osszekottetes-alapu, byte-folyam jelleg} adatatvitelt biztos t,
u
de megtartja a csomaghatarokat.
SOCK RAW
Alacsonyszint} kommunikacios protokollok
u
elereset teszi lehet}ve (ld. kes}bb).
o
o
A sockethoz a fenti t pusok alapjan ki lesz valasztva egy alapertelmezes szerinti
halozati protokoll, de ha az nem felel meg az igenyeknek, akkor a harmadik parameterben
ezt felulb ralhatjuk. Ha megfelel, akkor ott 0-t adjunk meg.
Az alapertelmezes szerinti halozati protokollok (socket type es domain alapjan) a
kovetkez}k:
o
AF INET AF NS
SOCK STREAM
TCP
SPP
SOCK DGRAM
UDP
IDP
SOCK SEQPACKET {
SPP
SOCK RAW
IP
IDP
A rendszerh vas visszateresi erteke hiba eseten -1, egyebkent pedig egy socketdescriptor, amivel kes}bb a socketra hivatkozhatunk.
o
Megjegyezzuk, hogy az IP protokoll elereser}l e fejezet vegen meg reszletesebben
o
is lesz szo, de addig a leggyakrabban hasznalt transzportprotokollokat: a TCP-t es az
UDP-t fogjuk attekinteni.
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5.6 Socket c menek kijelolese
Egy sockethoz a letrehozasa utan meg nincs semmifele c m hozzarendelve (egyes domainekben, ilyen peldaul az Internet, hozzarendel}dik egy "meg nem foglalt" c m, de az
o
nem mindig "a megfelel} c m", ezert gyakran szukseges annak a felulb ralata - peldaul
o
azert, hogy a szerver "well-known" portjanak a c met beall tsuk a szerver socket-jan).
Az altalaban igaz, hogy az operacios rendszer "nem oszt ki" alapertelmezeskent
bealll tott c mkent 5000-nel nagyobb port-szamot, ezert a sajat szervereinknek (amelyeknek egy szabad "well known" portot kell kiosztani) 5000-nel nagyobb sorszamu portot
nyugodtan kijelolhetunk.
A bind() rendszerh vassal lehet egy sockethoz egy c met rendelni. Ennek formaja a
kovetkez}:
o
bind(sd, name, namelength)

Itt sd a socket-le ro, a name parameter tartalmazza a pointert a sockethoz rendelend} c mre (Internet domainben pointer egy sockaddr in strukturara), es mivel a c mek
o
hossza domainenkent mas es mas, ezert a namelength parameter tartalmazza a name
parameterben lev} c m hosszat byteban merve.
o
(Fontos, hogy az Internet domainben egy szerver (mondjuk TCP) sockethoz a
hozzabind-olt IP-c m (sin addr) azt adja meg, hogy a socket melyik halozati csatlakozon
hajlando elfogadni rakapcsolodasi kerelmet. Ott a halozati csatlakozonak az IP c met
network byte orderben kell megadni, es van egy specialis konstans, az INADDR ANY,
amely azt jelenti ha sockethoz bind-oljuk, hogy a socket barmelyik halozati csatlakozon(!)
elfogad rakapcsolodasi kerelmet. "Hasznalat el}tt" termeszetesen ezt is network byte oro
der}re kell konvertalni.)
u

5.7 Kapcsolat letrehozasa
Erre az osszekottetes-alapu klienseknel es szervereknel van szukseg. A kapcsolatfelvetel
a szerver reszer}l ugy tortenik, hogy a szerver a socketjan vegrehajtja a listen() rendo
szerh vast, es ezzel bejelenti az operacios rendszernek, hogy a socketja kesz a kliensek
rakapcsolodasi kerelmeinek fogadasara. Az els} parameter itt is a socket-descriptor, m g
o
a masodik parameter egy egesz szam, es azt mondja meg, hogy ha egyszerre tobb kliens
is ra akarna kapcsolodni a szerver socketra, akkor hany rakapcsolodasi kerelmet rakjon
bele egy varakozasi sorba (a tobbit "eldobja", visszautas tja). Ennek erteke altalaban
(alapertelmezes szerint) 5. Ezutan a szerver az accept() rendszerh vassal vehet le a fenti
varakozasi sorbol (ciklusban ...) egy-egy kerelmet es kapcsolodhat a klienshez. (Ha nincs
ilyen kerelem, akkor a rendszerh vas var, am g lesz egy.) Az accept rendszerh vas els}
o
parametere egy socket-descriptor, masodik ill. harmadik parametere pedig egy socket-c m
struktura (c m szerint atadva ...) ill. egy c m-hosszat tartalmazo egesz szamra mutato
pointer, ahova a tavoli kommunikacios partner c menek a hosszat adja vissza a rendszer.
A masodik parameterben megadott c mre visszatereskor a rakapcsolt kliens c met rja
vissza. A rendszerh vas visszateresi erteke egy uj socket-descriptor, amivel a kapcsolatra
hivatkozni lehet.
A kapcsolat letrehozasa a klienseknel a connect() rendszerh vassal zajlik. Ennek
els} parametere a socket-descriptor, amin keresztul ra akarunk valahova kapcsolodni.
o
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Masodik parameter egy socket-c m struktura, ami a szerver c met tartalmazza. Harmadik
parametere pedig az el}bbi struktura hosszat adja meg. Visszateresi erteke -1, ha a
o
rendszerh vas sikertelen volt.
A rendszerh vasok alakja tehat a kovetkez}:
o
listen(sd, nrofreq)
newsd=accept(sd, name, namelength)
connect(sd, name, namelength)

Ezutan megkezd}dhet az adatatvitel.
o

5.8 Adatatvitel osszekottetes-alapu kapcsolatok eseten
Az adatatvitel tobbfelekeppen is mehet: mehet a read() ill.
recv() rendszerh vasokkal.
A write() rendszerh vas parameterezese a kovetkez}:
o

write()

vagy a send() es

write(sd, buff, size)

Ez a buff bu erb}l size darab byteot elkuld az sd socket-descriptorhoz tartozo
o
(halozati vagy mas) kapcsolatra.
A read() rendszerh vas parameterezese a kovetkez}:
o
read(sd, buff, size)

Ez a buff bu erbe size darab byteot beolvas az sd socket-descriptorhoz tartozo
(halozati vagy mas) kapcsolatrol.
Mindkett} rendszerh vas visszateresi erteke hiba eseten -1, egyebkent pedig az atvitt
o
byteok mennyisege (vigyazni kell! lehet, hogy size-nel kisebb!). Ha a tavoli gep a
halozati kapcsolatot lezarta, akkor a read rendszerh vas visszateresi erteke 0.
A send() rendszerh vas parameterezese a kovetkez}:
o
send(sd, buff, size, flags)

Ez a buff bu erb}l size darab byteot elkuld az sd socket-descriptorhoz tartozo
o
(halozati vagy mas) kapcsolatra.
A recv() rendszerh vas parameterezese a kovetkez}:
o
recv(sd, buff, size, flags)

Ez a buff bu erbe size byteot beolvas az sd socket-descriptorhoz tartozo (halozati
vagy mas) kapcsolatrol.
A fenti ket rendszerh vasnal ha a flags parameter 0, akkor ugyanugy viselkednek,
mint a read illetve write rendszerh vasok. Ezen k vul mas ertekekeit is felvehet, mint
peldaul az MSG OOB-t, ami azt jelenti, hogy a protokoll altal de nialt surg}s adatkent
o
kell az elkuldott byteokat kezelni. Masik specialis flag az MSG PEEK, amely a recv
rendszerh vasnal adhato at, es az eredmenye az, hogy az adatokat bemasolja a rendszer
a megadott bu erbe, de az eredeti helyukon is meghagyja. Mindegyik rendszerh vas az
atvitt (beolvasott ill. ki rt) adatbyteok szamat adja vissza.
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5.9 Adatatvitel nem oszekottetes-alapu kapcsolatok
eseten
Erre a kovetkez} ket rendszerh vast hasznalhatjuk:
o
sendto(sd, buff, size, flags, to, addrlen)
/*
* struct sockaddr *to
* int addrlen
*/
recvfrom(sd, buff, size, flags, from, addrlen)
/*
* struct sockaddr *from
* int *addrlen
*/

Ezeknel a rendszerh vasoknal az els} negy parameter nem szorul magyarazatra. Az
o
otodik parameter a sendto rendszerh vas eseten az adat rendeltetesi helyenek a c me,
m g a recvfrom rendszerh vas eseten ott adja vissza az operacios rendszer, hogy honnan
erkezett az adat. Az addrlen parameter a from ill. a to parameterben megadott c m
meretet tartalmazza!

5.10 Kapcsolat (socket) lezarasa
Ha egy socketot nem akarjuk tovabb hasznalni (nincs szukseg az onan jov} adatokra),
o
akkor le kell zarni. Erre a szokasos close rendszerh vast hasznalhatjuk. Alakja:
close(sd)

Oszekottetes-alapu socketoknal lehet}seg van arra is, hogy csak az egyikiranyu
o
adataramot zarjuk le (ekkor a socket nem sz}nik meg!). Ez a shutdown rendszerh vassal
u
megy.
Ennek alakja:
shutdown(sd, mode)

Itt sd a socket-descriptor, mode pedig 0, ha nem akarunk tobb adatot beolvasni a
socketrol, 1 pedig akkor, ha nem akarunk tobb adatot rni a socketra.

5.11 Tobb socket parhuzamos gyelese (select)
A select rendszerh vassal lehet}seg van parhuzamosan tobb socket allapotanak a o
gyelesere is (hogy erkezett-e ra adat vagy sem stb.). A rendszerh vas alakja:
nrofsdsfound=select(nsds, readsds, writesds, exceptsds, tmout)
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Az nsds parameter megmondja, hogy a 0-tol nsds-1 -ig terjed} socket- (ill. fajlo
)descriptorokat kell gyelnie a programnak. A readsds egy pointer, es azok a bitek vannak beall tva az altala mutatott helyen, amelyeket a 0..nsds-1 descriptor-intervallumbol
olyan szempontbol kell gyelni, hogy adat erkezett ra valahonnan. A writesds ehhez
hasonlo, de a rendszer ennel azt gyeli, hogy kesz van-e a socket adat kuldesere.
Az exceptsds hasonloan adja meg, hogy mely descriptorokat kell gyelni "kiveteles
esemenyek" szempontjabol (pl. surg}s adat erkezese). A tmout parameter egy pointer,
o
es ha NULL, akkor a rendszer addig var, am g valamely k vant esemeny bekovetkezik
egyebkent pedig a pointer altal mutatott c men lev} tmout strukturaban megadott
o
masodperc ill. microsec. ideig var valamely esemenyre, es ha semmi sem tortenik
addig, akkor TIMEOUT hibaval ter vissza. Megjegyzeeuk, hogy az, hogy egy socket
kesz az adatkuldesre csak annyit jelent, hogy a ra vonatkozo write/send rendszerh vasok
vegrehajtasukkor nem blokkolnak, es nem jelenti { peldaul egy esetleges halozati hiba
bekovetkezte utan { azt, hogy a halozati kapcsolat mar helyesen m}kodik, es az adat a
u
kommunikacios kapcsolat egyik veger}l a masikra atkuldhet}.
o
o
A C konyvtar szabvanyos makrokat bocsat a felhasznalo rendelkezesere, amelyekkel a
readsds/writesds/exceptsds mez}ket a socket-descriptorok alapjan konny} kitolteni
o
u
(ezeket a makrokat hasznaljuk, mert lehet, hogy kes}bb a bels} reprezentacio meg fog
o
o
valtozni).
Ezzel a rendszerh vassal lehet microsec. pontossagu orat a programba ep teni.

5.12 A kommunikacios partner c menek megszerzese
A folyamatok a szul}jukt}l gyakran orokolnek megnyitott socketokat. Ha egy folyao o
matnak szuksege van annak meghatarozasara, hogy ki van a socket-kapcsolat masik
vegen (oszekottetes-alapu kapcsolatok eseten), akkor azt megteheti a getpeername rendszerh vassal (ez egyes rendszerekben nem rendszerh vas, hanem konyvtari fuggveny, amit
valamilyen mas rendszerh vassal valos tanak meg, de ez most szamunkra nem erdekes).
Ennek alakja a kovetkez}:
o
getpeername(sd, name, namelength)

A name parameter egy socket-c m struktura, itt kapom vissza a partner c met. A
struktura harmadik eleme egy pointer egy egesz t pusu ertekre, amely a c m hosszat
tartalmazza (visszatereskor, es ez termeszetesen a visszaadott c m hosszara vonatkozik).
A sockethoz (explicit modon vagy defaultkent) rendelt helyi c met a getsockname rendszerh vassal lehet lekerdezni. Parameterezese ugyanaz, mint a getpeername
fuggvenye.

5.13 Halozatokkal
segedfuggvenyek

kapcsolatos

konyvtari

Ebben a reszben olyan hasznos konyvtari rutinok lesznek ismertetve, amelyre bonyolultabb, felhasznalobaratabb programok rasanal szukseg lehet.
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5.13.1 Hostnevr}l IP-c mre transzformacio
o

Sok programban szukseg van a fent eml tett transzformaciora. Ez a gethostbyname()
konyvtari rutinnal megy. Parametere a kerdeses host neve, es visszaad egy pointert, ami
a kovetkez} strukturara mutat (egy gethostbyname szamara statikus adatteruleten!) :
o
struct hostent {
char *h_name
/*
char **aliases /*
int h_addrtype /*
int h_length
/*
char *h_addr_list

A host hivatalos neve */
Alias-nevek tombje */
Pl. AF_INET ... */
A host cimenek a hossza */
/* A host cime(i), NULL-pointerrel
jelezve a lista veget. */

}

A rutin hasznalatara majd lathatunk peldakat a kes}bbiekben.
o

5.13.2 Halozati szolgaltatasok adatbazisa

A szabvanyos szerverek (mint peldaul az FTP vagy a TELNET) a halozatban minden hoston a megfelel} "jol ismert" porton varakoznak a kliensek rakapcsolodasara. A
o
"jol ismert" port sorszamat altalaban nem egetik bele a szerverbe, hanem egy kuls}
o
adatbazisban taroljak (a /etc/services leban), a programok onnan kerdezhetik le. Az
adatbazis lekerdezeset egy getservbyname() konyvtari fuggvennyel lehet elvegezni. Ez
egy servent strukturara mutato pointerrel ter vissza. A struktura szerkezete a kovetkez}:
o
struct servent {
char *s_name /* A szolgaltatas hivatalos neve */
char **s_aliases /* A szolgaltatas egyeb hasznalt nevei */
int s_port /* A port sorszama, ahol a szervernek a
a kliensekre kell varnia. Network byte
orderben */
char *s_proto /* A hasznalando protokoll */
}

Ha peldaul a TCP alapu FTP protokollt akarjuk hasznalni, akkor a kovetkez}kepp
o
kell a fent eml tett rutint hasznalni:
struct servent *sp
struct sockaddr_in serv_addr
...
/* serv_addr struktura kitoltese */
sp=getservbyname("ftp","tcp")
serv_addr.sin_port=sp->s_port
/* ... */
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5.14 A
socketokkal
rendszerh vasok

kapcsolatos

tovabbi

Ebben a reszben olyan socketokkal kapcsolatos dolgok lesznek ismertetve, amelyek nelkul
meg lehet ugyan elni, de "igenyesebb" programokat nem lehet ezek nelkul meg rni.

5.14.1 TCP surg}s adat tovabb tasa
o

Mint mar eml tve volt, a TCP lehet}seget ad surg}s adatok (TCP urgent data) kuldesere
o
o
is. A socket interface "generikus" ilyen iranyu megtervezese (vagyis az Out of Band
data kezelese) nagyon nehez volt, mivel az egyes protokollok mas-mas dolgokat engednek meg Out of Band data-nak. A TCP protokoll egyszerre akar tobb, es akarmilyen
hosszu uzenetet tud tovabb tani, m g mondjuk az XNS halozat egy id}ben legfeljebb 1
o
bytenyi surg}s adatot (Out of Band data-t) tud kezelni (ha csak ezt az XNS lehet}seget
o
o
hasznaljuk ki a programunkban, akkor konnyen atvihet} lesz TCP-re, m g ford tva ez
o
nem szokott menni). Meg az is bonyol tja a helyzetet, hogy a TCP mar azel}tt jelezni
o
kepes a kommunikacios partnernek a surg}s adat letezeset, meg miel}tt maguknak az
o
o
adatoknak az atvitele megtortenne.
A surg}s (OOB) adatok elkuldese es fogadasa annyibol all, hogy a send() ill. recv()
o
rendszerh vasoknal megadjuk az MSG OOB konstans aget. Az OOB adatokat a tobbi
"normal" adattol teljesen fuggetlenul lehet beolvasni (mintha egy kulon kommunikacios
csatornan kapnank oket), es az
}
ioctl(sock, SIOCATMARK, &answer)
ioctl() rendszerh vassal kerdezhetjuk meg az operacios rendszert}l, hogy a "normal"
o
adatfolyamnak ezen a pontjan kuldtek-e az OOB adatot (eszerint a feltetel szerint lesz
az answer==1 all tas igaz vagy hamis, azaz az answer valtozo erteke 1 lesz, ha az adatfolyamnak ezen a pontjan kuldtek az OOB adatot). Lasd erre a kovetkez} peldat!
o
sigurg_signal_handler()
{
int atmark, buf 1024]
while(1) {
if (ioctl(sock, SIOCATMARK, &atmark)<0) {
perror("ioctl")
exit(2)
}
if (atmark) break
read(sock, buf,1024)
}
if (recv(sock, &atmark, 1, MSG_OOB) <0) {
perror("recv")
exit(1)
}
}
}
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A fenti programresz a SIGURG signal (a SIGURG signal azt jelzi, hogy surg}s adao
tot kuldott a kommunikacios partner, de nem biztos, hogy azt mar meg is kaptuk ...)
kezeleset vegzi. Beolvassa (es "eldobja") a normal adatokat egesz addig, am g a surg}s
o
adat elkuldesi helyeig el nem jut, es ott beolvas 1 bytenyi surg}s adatot. (A SIGURG
o
signalrol ld. a kovetkez} pontot.)
o

5.14.2 A socketokhoz kapcsolodo SIGIO es SIGURG
signalok

Az eddigiekben csak a socketok "szinkron" modu kezeleser}l volt szo (vagyis amikor
o
a rendszerh vasok csak azutan fejez}dnek be, miutan az operacios rendszer a m}veletet
o
u
teljesen elvegezte). Lehet}seg van bizonyos esemenyeknek az "aszinkron" modu kezelesere
o
is. Ezzel kapcsolatosak az operacios rendszer SIGIO es SIGURG nev} signaljai.
u
A rendszert "meg lehet kerni" a korabban mar bemutatott signal() rendszerh vassal, hogy olyan esetekben kuldjon egy SIGIO signalt valamelyik folyamatnak,
amikor valamelyik socketon (beolvasando) adat erkezett. Hasonlo modon kerhet} a
o
"surg}s adat erkezeset" jelz} signal is. Ehhez el}szor a signal() rendszerh vassal a
o
o
o
k vant signal-handler eljarast ki kell jelolni, majd meg kell adni annak a folyamatnak az azonos tojat ( fcntl(socketdescriptor, F_SETOWN, procid) ) rendszerh vassal, amelynek a signalt kuldeni kell es vegul "engedelyezni" kell a signal-kuldest
egy ( fcntl(socketdescriptor, F_SETFL, FASYNC) ) rendszerh vassal (vagyis ezzel
azt mondjuk meg az operacios rendszernek, hogy a signal-handler "kesz" a signalok fogadasara).
Erre pelda a kovetkez} programreszlet (itt mindket signal-handlert kijeloltuk, de ez
o
nem "kotelez}" - a sajat programunkba csak azt kell belerakni, amelyre szuksegunk van).
o
#include <fcntl.h>
#include <signal.h>
#include <errno.h>
int iosignalhandler()
int urgsignalhandler()
int sd
..
sd = socket( ... )
..
signal(SIGIO,iosignalhandler)
signal(SIGURG,urgsignalhandler)
if (fcntl(sd,F_SETOWN,getpid())<0) { /* Mi kapjuk a signalt */
perror("hiba az 1. fcntl-nel")
exit(1)
}
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/* Ezutan

kapunk majd signalokat - ha valami erkezik */

if (fcntl(sd,F_SETFL,FASYNC)<0) {
perror("hiba a 2. fcntl-nel")
exit(1)
}

5.14.3 UDP broadcast lehet}seg
o

Lehet}seg van arra is, hogy a (helyi) Ethernet halozatra kapcsolt (vagyis a kabelre
o
zikailag rakotott) hostok mindegyikenek "egy m}velettel" (egyszerre) kuldjunk valamu
ilyen uzenetet (magyaran broadcast uzenetet kuldjunk).
Ezt a kovetkez} socket-opcio beall tasaval lehet elerni:
o
if ((setsockopt(s,SOL_SOCKET,SO_BROADCAST,&on,sizeof(on))<0) {
/*
* hiba a setsockopt-nal ...
*/
perror("hiba a setsockpt-nal")
....
}

Ezutan a sockethoz kell rendelni egy c met (AF INET c mformatummal, INADDR ANY c mmel, es annak az UDP portnak a sorszamat kell hozzarendelni, amelyre
a broadcast uzenetet a tobbi gepen kuldeni akarjuk.)

5.14.4 Socket aszinkron uzemmodra all tasa

Az accept(), connect() es write() rendszerh vasoknak esetenkent varniuk kell, am g
valamekkora memoria felszabadul. Ez azt jelenti, hogy ha egy folyamat a fenti rendszerh vasok kozul vegrehajt egyet, es epp nincs eleg szabad memoria (egy specialisan erre
a celra kijelolt kernel-teruleten), akkor a folyamat nem fut tovabb, am g a szukseges
mennyiseg} memoria fel nem szabadul. Ezt meg lehet kerulni a kovetkez} peldaban
u
o
bemutatott rendszerh vassal:
#include <fcntl.h>
..
sd=socket( ... )
..
if (fcntl(sd,F_SETFL,FNDELAY) < 0) {
perror("hiba az fcntl-nel")
exit(1)
}
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Ezutan a fent eml tett rendszerh vasok kozul az accept() es a connect() negat v
(vagyis hibat jelz}) visszateresi ertekkel ter vissza, es az errno valtozoba EWOULDo
BLOCK hibakod kerul, ha a rendszerh vas vegrehajtasahoz a rendszernek varnia kellene.
Ekkor a rendszerh vas nem hajtodik vegre. Az adatkuld} (pl. write() es send()) rendo
szerh vasok (amelyek visszateresi ertekkent az elkuldott adatbyteok szamat adjak vissza)
ha nincs eleg memoria, akkor (esetleg) kevesebb byteot kuldenek el, es ezt adjak vissza.

5.15 Peldak a socket rendszer hasznalatara
A kovetkez} pontok egy-egy peldan keresztul mutatjak be a leggyakoribb kliens es szerver
o
feladatokat UNIX kornyezetben. Termeszetesen a valos ELETBEN mas kliens es szerver
strukturak is leteznek, de itt nincs lehet}seg mindent bemutatni.
o

5.15.1 Pelda egy egyszer} iterat v osszekottetes-alapu
u
szerverre

A kovetkez} program lefoglal egy TCP portot, ki rja annak a c met a keperny}re, es
o
o
vegtelen ciklusban var a TCP-porton egy kapcsolatra, es kiszolgalja a rakapcsolodott
klienst (a szolgalat annyi, hogy a kliens altal elkuldott byteokat a szabvanyos kimenetre
ki rja).
/*
* Pelda arra, hogy hogyan mukodik egy (iterativ) szerver.
* A program vegtelen ciklusban figyel egy adott TCP portot, beolvassa
* es a kepernyore irja az onnan jovo byteokat, majd uj kapcsolatra
* var.
*/
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#define TRUE 1

/* sockaddr_in struktura */
/* /etc/hosts tabla */

main()
{
int sock, length
struct sockaddr_in server
int msgsock
char buf 1024]
int retval
int i
sock = socket(AF_INET, SOCK_STREAM, 0)
if (sock < 0) {
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perror("hiba a socket-nel")
exit(1)
}
server.sin_family = AF_INET
server.sin_addr.s_addr = htonl(INADDR_ANY)
server.sin_port = htons(0)
if (bind(sock, &server, sizeof(server))) {
perror("hiba a bind-nel")
exit(1)
}
length = sizeof(server)
if (getsockname(sock, &server, &length)) {
perror("hiba a getsockname-nel")
exit(1)
}
fprintf(stderr,"TCP port:%d\n", ntohs(server.sin_port))
listen(sock, 5)
while(1) {
msgsock = accept(sock, 0, 0)
if (msgsock == -1)
perror("hiba az accept-nel")
else do {
bzero(buf, sizeof(buf))
if ((retval = read(msgsock, buf, 1024)) < 0)
perror("hiba a read-nel")
i = 0
if (retval == 0)
fprintf(stderr,"Kapcsolat lezarva\n")
else
fprintf(stderr,"String:%s\n", buf)
} while (retval != 0)
close(msgsock)
}
close(sock) /* Sosem sullyedunk idaig */

}

5.15.2 Pelda egy osszekottetes-alapu kliensre

A kovetkez} program a megadott host megadott TCP portjaval felep t egy kapcsolatot,
o
es adatokat kuld at oda.
/*
* Hasznalata: programnev hostnev TCPport-number
*
* A program letrehoz a megadott hoston, a megadott TCP porttal
* egy kapcsolatot. Rair egy uzenetet es megall.
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*/
#include
#include
#include
#include
#include

<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<netdb.h>
<stdio.h>

#define DATA "Isten hozta ornagyur."
main(argc, argv)
int argc
char *argv ]
{
int sock
struct sockaddr_in server
struct hostent *hp, *gethostbyname()
char buf 1024]
sock = socket(AF_INET, SOCK_STREAM, 0)
if (sock < 0) {
perror("hiba a socket-nel")
exit(1)
}
server.sin_family = AF_INET
hp = gethostbyname(argv 1])
if (hp == NULL) {
fprintf(stderr, "%s: ismeretlen host\n", argv 1])
exit(2)
}
bcopy(hp->h_addr, &server.sin_addr, hp->h_length)
server.sin_port = htons(atoi(argv 2]))
if (connect(sock, &server, sizeof(server)) < 0) {
perror("hiba a connect-nel")
exit(1)
}
if (write(sock, DATA, sizeof(DATA)) < 0)
perror("hiba a write-nal")
close(sock)
}
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5.15.3 Pelda egy select-et hasznalo osszekottetes-alapu
szerverre

A kovetkez} program lefoglal egy TCP portot, ki rja annak a c met a keperny}re, es
o
o
vegtelen ciklusban var a TCP-porton egy kapcsolatra, es kiszolgalja a rakapcsolodott
klienst (a szolgalat annyi, hogy a kliens altal elkuldott byteokat a szabvanyos kimenetre
ki rja). Ha egy megadott id}n belul nem erkezik egy klienst}l sem rakapcsolodasi igeny,
o
o
akkor megfelel} hibauzenetet r ki, es el}r}l kezdi az egeszet.
o
oo
/*
* Ez egy egyszeru szerver, amely var egy kliens rakapcsoladasara, de
* egy timeout erteket is definial, es ha azon az idon belul nem
* kapcsolodik ra egy kliens sem, akkor azt eszreveszi es fut tovabb.
*/
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#define TRUE 1
main()
{
int sock, length
struct sockaddr_in server /* Internet domain-beli cim */
int msgsock /* Erre a socket-descriptorra accept-alja
a kapcsolatot */
char buf 1024]
int retval
fd_set ready
struct timeval to /* timeout erteke */
sock = socket(AF_INET, SOCK_STREAM, 0)
if (sock < 0) {
perror("hiba a socket-nel")
exit(1)
}
server.sin_family = AF_INET
server.sin_addr.s_addr = htonl(INADDR_ANY)
server.sin_port = htons(0)
if (bind(sock, &server, sizeof(server))) {
perror("hiba a bind-nal")
exit(1)
}
length = sizeof(server)
if (getsockname(sock, &server, &length)) {
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perror("hiba a getsockname-nel")
exit(1)
}
fprintf(stderr,"TCP port:%d\n", ntohs(server.sin_port))
/* Kliensekre var */
listen(sock, 5)
while(1) {
FD_ZERO(&ready) /* \"ures halmazt hoz l\'etre */
FD_SET(sock, &ready) /*sock socketot figyelni kell */
to.tv_sec = 5 /* Timeout
*/
to.tv_usec=0 /* Microsec. */
if (select(sock + 1, &ready, NULL, NULL, &to) < 0) {
perror("hiba a select-nel")
continue
}
if (FD_ISSET(sock, &ready)) { /* Be van allitva? */
msgsock=accept(sock,(struct sockaddr *)0,
(int *)0)
if (msgsock == -1)
perror("hiba az accept-nel")
else do {
bzero(buf, sizeof(buf))
if ((retval=read(msgsock,buf,1024))<0)
perror("hiba a read-nel")
else if (retval == 0)
fprintf(stderr,"End...\n")
else
fprintf(stderr,"%s\n", buf)
} while (retval > 0)
close(msgsock)
} else
fprintf(stderr,"Nincs kapcsolat ... \n")
}
close(sock) /* Idaig nem sullyedhetunk */
}

5.15.4 Pelda egy konkurrens osszekottetes-alapu szerverre

A kovetkez} program lefoglalja az 5678-as TCP portot, ki rja annak a sorszamat a
o
keperny}re (vagyis az 5678-at), es vegtelen ciklusban var azon a TCP-porton egy kapco
solatra. Ha egy kliens ra akar kapcsolodni, akkor elfogadja a rakapcsolodasi kerelmet,
majd szul egy gyermek-folyamatot, amely a szokasos (korabban is latott) "szolgaltatast"
elvegzi.
A SIGCLD signalt a program ignoralja, gy a meghalt gyermek-folyamatok nem "hal-
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mozodnak fel" zombi-proceszek formajaban.
/*
* Pelda arra, hogy hogyan mukodik egy (konkurrens) szerver.
* A program vegtelen ciklusban figyel egy adott TCP portot, beolvassa
* es a kepernyore irja az onnan jovo byteokat, majd uj kapcsolatra
* var.
*/
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#include <signal.h>
#define TRUE 1
main()
{
int sock, length
struct sockaddr_in server
int msgsock
char buf 1024]
int retval
int i
signal(SIGCLD,SIG_IGN)
sock = socket(AF_INET, SOCK_STREAM, 0)
if (sock < 0) {
perror("hiba a socket-nel")
exit(1)
}
server.sin_family = AF_INET
server.sin_addr.s_addr = htonl(INADDR_ANY)
server.sin_port = htons(5678)
if (bind(sock, &server, sizeof(server))) {
perror("hiba a bind-nel")
exit(1)
}
length = sizeof(server)
if (getsockname(sock, &server, &length)) {
perror("hiba a getsockname-nel")
exit(1)
}
fprintf(stderr,"TCP port:%d\n", ntohs(server.sin_port))
listen(sock, 5)
do {

5.15. PELDAK A SOCKET RENDSZER HASZNALATARA

101

msgsock = accept(sock, 0, 0)
if (msgsock == -1)
perror("hiba az accept-nel")
else
{
if (fork() == 0)
{ /* Gyermek processz */
close(sock)
do {
bzero(buf, sizeof(buf))
if ((retval = read(msgsock, buf, 1024)) < 0)
perror("hiba a read-nel")
i = 0
if (retval == 0)
fprintf(stderr,"Kapcsolat lezarva\n")
else
fprintf(stderr,"String:%s\n", buf)
} while (retval != 0)
close(msgsock)
exit(0)
}
else
{
close(msgsock)
}
}
} while (TRUE)
close(sock) /* Sosem sullyedunk idaig */
}

5.15.5 Pelda egy osszekottetes-mentes (datagram) szerverre
A kovetkez} program lefoglal egy UDP portot, ki rja annak a c met a keperny}re, es var
o
o
az UDP-porton egy datagramra, es ha kap egyet, akkor ki rja a tartalmat.
#include
#include
#include
#include

<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<stdio.h>

/*
* A program letrehoz egy UDP socketot, nevvel latja el, es egy ra
* erkezo csomagot fogad es kiir.
*/
main()
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{

int sock, len
struct sockaddr_in server, from
char buf 1024]
int addrlen
sock = socket(AF_INET, SOCK_DGRAM, 0)
if (sock < 0) {
perror("hiba a socket-nel")
exit(1)
}
server.sin_family = AF_INET
server.sin_addr.s_addr = htonl(INADDR_ANY)
server.sin_port = htons(0)
if (bind(sock, &server, sizeof(server))) {
perror("hiba a bind-nal")
exit(1)
}
len = sizeof(server)
if (getsockname(sock, &server, &len)) {
perror("hiba a getsockname-nel")
exit(1)
}
fprintf(stderr,"UDP port:%d\n", ntohs(server.sin_port))
if (recvfrom(sock, buf, 1024, 0, &from, &addrlen) < 0) {
perror("hiba a recvfrom-nal")
exit(2) }
fprintf(stderr,"Fogadott szoveg: >>%s<<\n", buf)
close(sock)
}

5.15.6 Pelda egy osszekottetes-mentes (datagram)
kliensre
A kovetkez} program a megadott host megadott UDP portjara adatokat kuld.
o
#include
#include
#include
#include
#include

<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<netdb.h>
<stdio.h>

#define DATA "Isten hozta ornagyur ..."
/*

5.16. A HALOZATI RETEG (IP PROTOKOLL) ELERESE
* Hivas: udpkliens hostname port-nr.
*
* Ez a program a parametereben megadott hostra, es a megadott
* UDP-portra kuld egy datagramot.
*/
main(argc, argv)
int argc
char *argv ]
{
int sock
struct sockaddr_in server
struct hostent *hp, *gethostbyname()
sock = socket(AF_INET, SOCK_DGRAM, 0)
if (sock < 0) {
perror("hiba a socket-nel")
exit(1)
}
hp = gethostbyname(argv 1])
if (hp == NULL) {
fprintf(stderr, "%s: ismeretlen host\n", argv 1])
exit(2)
}
bcopy(hp->h_addr, &server.sin_addr, hp->h_length)
server.sin_family = AF_INET
server.sin_port = htons(atoi(argv 2]))
if (sendto(sock,DATA,sizeof(DATA),0,&server,sizeof(server))<0)
perror("hiba a sendto-nal")
close(sock)
}

5.16 A halozati reteg (IP protokoll) elerese
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Fejezet 6
Security
Ebben a fejezetben az operacios rendszerekkel kapcsolatban felmerul} biztonsagossagi
o
kerdesekr}l lesz szo (leginkabb a UNIX rendszerben felmerul} gondokrol). Ez a ny lt
o
o
rendszerekkel kapcsolatban az egyik legfontosabb kerdeskor, mert a fajlrendszerben (es a
rendszer tobbi reszeben) tarolt informaciok a tulajdonosuknak komoly erteket jelenthetnek. A biztonsagossagra f}leg a halozatok jelenlete miatt kell ugyelni (mivel mondjuk
o
egy hibasan, atgondolatlanul meg rt FTP-szerver akar mindenkinek mindent megengedhet - mivel ez egyes implementaciokban az FTP szerver gyakran setuid root program azaz
vegrehajtasakor szuperfelhasznaloi jogokkal rendelkezik). Tehat a hangsuly a rendszerhez
valo hozzaferes szabalyozasan valamint a kommunikacio biztonsagossa tetelen van (nem
szabad megengedni, hogy a rendszerben tarolt adatokhoz illetektelenek hozzaferjenek)
- az nyilvanvalo, hogy ez a kerdes tulmutat az adattitkos tas kerdesen - es az elet mas
teruleteivel is szoros kapcsolatban van: peldaul a rend}rseg hozzaferhet az emberekr}l
o
o
tarolt adatokhoz vagy sem vagy mi szam tson banktitoknak?
Bizonyos szempontbol ide tartozik az adatvesztes elkerulese is (pl. mert leeg a haz,
vagy veletlenul rossz oppyt formattalunk, ), de ezekkel a kerdessel itt nem akarok
foglalkozni (nem is igen tudnek mit rni, azon k vul, hogy rendszeresen csinaljunk minden
adathordozon tarolt informaciorol biztonsagi masolatot).
:::

6.1 Tervezesi elvek
A kovetkez} pontok nehany hasznos szempontot mutatnak be, amelyet biztonsagi rendo
szerek tervezesekor erdemes kovetni:
A rendszerterv es a hasznalt biztonsagi protokoll legyen nyilvanos. Konnyelm}seg
u
azt feltetelezni, hogy a rendszerbe behatolni akarok azt nem fogjak ismerni.
Alapertelmezes mindig legyen az, hogy valaki valamihez nem ferhet hozza.
A securityvel kapcsolatos kerdeseket a rendszer tervezesenek korai fazisaban
tisztazni kell, es a security csomagot a rendszer magjaba integralni kell - annak
nincs sok ertelme, hogy egyetlen modult megcsinalunk ugy, hogy az nagyon er}s
o
biztonsagi el} rasoknak feleljen meg, a tobbi modul pedig nem tartalmaz ilyen celu
o
reszeket.
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Az alkalmazott biztonsagi intezkedesek pszichologiailag elfogadhatoak legyenek. A
rendszert valosz n}leg emberek fogjak hasznalni, ezert a rendszert "baratsagossa"
u
kell tenni.
Ha lehet keruljuk az egesz rendszer felett "teljes hatalommal b ro" rendszergazda
(superuser, supervisor ...) koncepciot. A rendszert bontsuk moduljaira (valamilyen
szempontok szerint - mondjuk egy-egy modul egy-egy fontosabb er}forras kezeleset
o
vegezze), es az egyes moduloknak legyenek (kulon-kulon) felugyel}i.
o

6.2 A felhasznalo azonos tasa
Komoly problemat jelent a felhasznalo azonos tasa a rendszerrel szemben (mindig
felmerulhet a kerdes, hogy a felhasznalo tenyleg az, akinek vallja magat?). Erre is letezik
mar tobb (pszichologiailag is elfogadhato) megoldas - a leggyakoribbak a kovetkez}k:
o
A felhasznalonak van valamilyen jelszava, amit csak } (es mondjuk az operacios
o
rendszer) tud, es a rendszer a bejelentkezeskor ezt a jelszot megkerdezi t}le. Ha
o
a felhasznalo a jelszot beadja, es az egyezik a rendszer altal ismert jelszoval, akkor
nagy a valosz n}sege annak, hogy az a szemely, aki bejelentkezett tenyleg az,
u
akinek kiadja magat. Ilyen rendszerekben problemat az okoz, hogy hol tarolja
a rendszer a jelszavakat. Ezt vagy ugy oldjak meg, hogy a jelszofajl egy specialis
fajl-attributummal van ellatva, es senki sem olvashatja el a tartalmat (de ekkor
biztonsagi masolatot sem lehet rola kesz teni!). Egy masik modszer a jelszofajl
tarolasara az, amit a UNIX operacios rendszernel alkalmaznak: a jelszofajl mindenki altal olvashato (altalaban /etc/passwd a neve). Viszont ebben a fajlban
a jelszo nem ny lt szoveg, hanem titkos tott formaban van tarolva (a 2. oszlopban van a jelszo). Amikor a rendszerbe bejelentkezik egy felhasznalo, es
beadja a jelszavat, akkor a rendszer elvegzi rajta a "szokasos" (de termeszetesen
egyiranyu) titkos tasi folyamatot, es az eredmenyt osszehasonl tja a jelszofajlban
tarolt titkos tott jelszoval. Ha a kett} megegyezik, akkor a felhasznalo jo jelszot
o
adott be, es be lehet engedni a rendszerbe.
Gyakran hasznalnak un. egy alkalomra szolo jelszavakat. Ekkor a felhasznalo
kap egy fuzetet, amelyben mondjuk a kovetkez} 1000 bejelentkezeshez szukseges
o
jelszavak vannak. Ennek a modszernek az a gyenge pontja, ha a felhasznalo elveszti
ezt a fuzetet.
Mas modszer a kerdes-feleletek modszere. Ekkor a felhasznalo (mondjuk amikor
el}szor leult a gephez) beadott az operacios rendszernek nagyon sok kerdest es
o
rajuk a helyes valaszokat. Egy kovetkez} bejelentkezeskor az operacios rendszer
o
ezek kozul a beadott kerdesek kozul valaszt talalomra mondjuk otot, es megkerdi
rajuk a valaszt. Ha a valaszok helyesek, akkor a felhasznalot beengedi a rendszerbe.
Az azonos tas tortenhet akar zikai es biologiai tulajdonsagok felhasznalasaval is
(pl. a retina erezete az emberekre jellemz}, es hosszu id}n keresztul lenyegeben
o
o
allando - ezt kihasznalva lehet egy olyan berendezest csinalni, amelybe a bejelentkezeskor bele kell nezni, es elvegzi az azonos tast).
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6.3 A 4.3BSD UNIX r-programjai
A 4.3BSD UNIX-ban vannak tobb olyan program, amely lehet}ve teszi, hogy fajlokat
o
masoljunk egyik hostrol a masikra (rcp - remote copy) parancs, egy masik hoston shell
scripteket futtassunk (rsh - remote shell) vagy bejelentkezzunk valamely mas hostra es
azon interakt van dolgozzunk (rlogin - remote login).
Ezek a programok lehet}seget nyujtanak annak megadasara, hogy ezek a
o
szolgaltatasok mely hostokrol erhet}ek el - ezzel bizonyos foku illetekessegvizsgalatra
o
adnak lehet}seget.
o
Erdemes megnezni, hogy hogyan tortenik mindez!
A 4.3BSD UNIX-os hostokon van egy /etc/hosts.equiv nev} le, amely tartalmazza
u
azoknak a hostoknak a neveit, amelyeken azonosak a kiosztott useridek (felhasznaloi
nevek) a helyi hoston lev} kiosztassal. Ekkor ha egy ilyen "ekvivalens" hostrol mondjuk a
o
kutya nev} felhasznalo egy fajlt akar masolni egy olyan helyi directoryba, amelyre a helyi
u
kutya nev} felhasznalonak rasi joga van, akkor ez a m}velet meg van engedve. Van egy
u
u
masik fontos fajl is: a .rhosts nev} (ez a felhasznalo HOME-directoryjaban talalhato).
u
Ebben is lehetnek hostnevek felsorolva (ahol a tulajdonos userid-je (login neve!) megegyezik a helyi login-nevvel) vagy lehetnek benne (hostnev,login-nev) parok is. Ez
utobbi esetben ha a tavoli hostrol a megadott login-nev} felhasznalo be akar jelentkezni
u
annak a felhasznalonak a login-nevevel, akinek a HOME directoryjaban a .rhosts le
ezt a (hostnev,login-nev) part tartalmazza, akkor az azonos tas a jelszo bekerese nelkul
sikeresnek tekinthet}.
o
Ha sajat szervereket runk, ahol ezt az r-programokban alkalmazott illetekessegvizsgalatot a ruserok() konyvtari fuggvennyel vegezhetjuk el. Ennek alakja:
ret=ruserok(rhost, superuser, remote_username, local_username)
char *rhost
int superuser
char *remote_username
char *local_username

Eredmeny: ret=0, ha az illetekessegvizsgalat sikeres volt, azaz a felhasznalo belephet
jelszobeadas nelkul, egyebkent ret erteke -1 lesz. (Az rhost parameter annak a hostnak
a nevet tartalmazza, amelyr}l be akarnak jelentkezni (gethostbyaddr(getpeername()))
o
modon kaphatjuk ezt meg. A superuser valtozo akkor 1, ha a bejelentkez} ezen a gepen
o
superuser jogokat akar-e kapni. A maradek ket parameter a tavoli es a helyi hostokon a
felhasznaloi nevek.)

6.4 A Kerberos illetekesseg-vizsgalo protokoll
A Kerberos elkesz tesenek celja az volt, hogy a halozatba rakott "nem megb zhato"
szam togepekkel se lehessen a rendszerben illetektelenul dolgozni, a szerver es a kliens
kozt aramlo adatokat titkos tani lehessen, es a kliensek ne tagadhassak le kiletuket
a szerverek el}tt. A Kerberos rendszer a kovetkez}keppen m}kodik:
o
o
u
Van egy bels} adatbazis, amely (azonos to, kulcs) parokat tarol, ahol az azonos tok
o
kozott el}fordul az egesz rendszerhez hozzafer} osszes felhsznalo azonos toja, es minden
o
o
egyes szerverhez is tartozik egy-egy azonos to.
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Amikor a felhasznalo bejelentkezik valamelyik szam togepbe, es mar be rta a nevet
a login: uzenet utan, a login program (aki a bejelentkezeskor fellep} feladatokat
o
vegzi el) egy uzenetet kuld a Kerberos illetekesseg-vizsgalo szervernek. Az uzenet
tartalmaz ket szoveget: az egyik szoveg a felhasznalo azonos toja, a masik szoveg
pedig az un. jegykiado szerver (ticket-granting szerver, TGS) nevet tartalmazza
(ennek a szereper}l kes}bb lesz szo).
o o
Az illetekesseg-vizsgalo szerver a fent eml tett adatbazisbol kikeresi a kapott
uzenetben lev} ket azonos tohoz tartozo kulcsokat (a felhasznaloi azonos tohoz
o
tarolt kulcs megegyezik a felhasznalo titkos tott jelszavaval). Ezutan a szerver
egy valaszuzenetet kuld vissza, ami tartalmaz egy titkos un. TGS-kulcsot, es egy
un. jegyet. Ez a TGS-jegy tartalmazza a felhasznaloi azonos tot, a jegykiado szerver (TGS) nevet, annak a szam togepnek az Internet c met, amelyen a felhasznalo
dolgozik, es a fent eml tett TGS-kulcsot. A TGS-jegy az uzenetben titkos tva van
a felhasznalo altal nem ismert kulccsal (a jegykiado szerver azonos tojahoz tartozo
kulccsal), es a teljes uzenet titkos tva van a felhasznalo titkos tott jelszavaval, hogy
mas ne ferjen hozza a tartalmahoz.
A felhasznalo jelszavanak beadasa utan az azonos to szervert}l visszakapott
o
uzenetet a login program a felhasznalo titkos tott jelszavaval dekodolja, es a TGSkulcsot valamint a (titkos tott) TGS-jegyet eltarolja.
Ezutan ha a felhasznalonak valamilyen halozati szolgaltatasra van szuksege, akkor
a jegykiado szervert}l (TGS-t}l) kernie kell egy "jegyet" a k vant szerverhez, es a
o
o
szervernel ezzel a jeggyel azonos thatja magat.
Ha peldaul a nyomtato szervert akarjuk hasznalni, akkor ahhoz egy jegy keresehez
a jegykiado szerverhez egy olyan uzenetet kell kuldeni, amely a korabban eltarolt
TGS-jegyet, a nyomtato szerver nevet es egy, a korabban megkapott TGS-kulccsal
titkos tott adatmez}t (ellen}rz} mez}t). Ez az ellen}rz} mez} tartalmazza a felo
o o o
o o o
hasznalo bejelentkezesi nevet, a gepjenek az Internet c met, es a pillanatnyi id}t.
o
A jegykiado szerver a kapott uzenet ellen}rzese utan valaszuzenetet kuld, amiben
o
van egy uj kulcs, es egy uj (titkos tott) jegy. Ez a titkos tott jegy a szolgaltatast
ker} kiletet igazolja, es a nyomtato szerver kulcsaval van titkos tva (ami a Kerberos
o
adatbazisaban van, es csak a nyomtato szerver es a Kerberos ferhet hozza
- ui. a nyomtato szerverbe peldaul "be van huzalozva".). A valaszuzenet a korabbi
TGS-kulccsal van titkos tva.
A felhasznalo programja az uzenetet dekodolja, es a nyomtato szervernek a fenti
"uj jegyet" kell elkuldenie (masik ket adatmez} mellett), ezzel igazolhatja kiletet.
o
A masik ket adatmez}k kozul az egyik a nyomtato szerver nevet, a masik pedig (a
o
korabban eml tett ellen}rz} mez}hoz hasonloan) a felhasznalo bejelentkezesi nevet,
o o o
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a gepjenek az Internet c met, es a pillanatnyi id}t tartalmazza (ez a mez} az el}z}
o
o
oo
pontban eml tett uj kulccsal van titkos tva, ezert ezt a nyomtato szerver dekodolni
tudja).
A ket helyen is eml tett ellen}rz} mez} tartalmazza a pillanatnyi id}t is. Ez azert
o o o
o
lenyeges, mert ezek az "igazolvanyok" viszonylag rovid elettartalmuak, nehogy valami
illetektelen "halozatlehallgato" ujra fel tudja hasznalni. Viszont ekkor meg kell oldani
azt, hogy a halozatban lev} gepek orajai nagyjabol egyutt legyenek.
o

6.5 Tanacsok setuid root programok rasahoz
Ha lehet ne rjunk ilyen programokat, mivel ezek futtataskor korlatozas nelkul
garazdalkodhatnak a rendszerben (ez talan a legkomolyabban legmegfontolandobb
tanacs). Ha arra van szukseg, hogy bizonyos fajlokhoz (itt nem rendszerfajlokra gondolok, hanem mondjuk egy programmal szall tott licensz-fajl vagy valami hasonlo) csak
a program ferjen hozza, akkor eleg mondjuk egy uj felhasznalot letrehozni, es a programhoz tartozo "kenyes" fajlokat ezen uj felhasznalo tulajdonakent kell kezelni, es amely
programnak ehhez hozza kell fernie, azt el kell latni egy setuid bittel (de ett}l meg nem
o
setuid root programot kapunk!).
A setuid root programok rasakor torekedjunk arra, hogy minel rovidebb legyen a
program azon szakasza, ahol a program kihasznalhatja azt, hogy "mindent szabad neki".
Peldaul azokat a szervereket szoktak setuid root bittel ellatni, amelyek a felhasznalotol
megkovetelik, hogy beadja a jelszavat es a login nevet (userid-jet). Ha jo a beadott
jelszo, akkor a szerver vegrehajtja a setuid() es setgid() UNIX rendszerh vasokat
annak a felhasznalonak a felhasznaloi- illetve csoport-azonos tojaval, aki bejelentkezett,
es a szerver ezutan mar el is veszti a superuser jogokat - ezutan mar csak azt szabad neki
is, amit a bejelentkezett felhasznalo interakt van is megtehetne a rendszerben.
Ha egy szervert ugy akarunk meg rni, hogy azt barki hasznalhassa anelkul, hogy
tenylegesen bejelentkezett volna a rendszerbe (mint peldaul az anonymous FTP
szolgaltatas), akkor hozzunk letre egy uj felhasznalot (az anonymous FTP szolgaltatas
eseten ennek a felhasznalonak mindig ftp a neve), amelyre a szerver olyankor setuid()el (es setgid()-el), ha a kliens nem tudott neki mas ("jobb") felhasznaloi azonos tot es
jelszot beadni.
A setuid root programok minden fajlhoz hozzafernek - fuggetlenul attol, hogy ki
ind totta el }ket. A UNIX operacios rendszer lehet}seget nyujt a korabban bemutatott
o
o
access() rendszerh vassal, hogy egy fajlra vonatkozoan eldontsuk, hogy aki a setuid root
programot elind totta, az a sajat jogan olvashatja-e, felul rhatja-e es vegrehajthatja-e azt
a fajlt. (Ez az ut azert jarhato, mert az access() a valodi felhasznaloi azonos to alapjan
vizsgalja a jogokat, nem pedig az e ektiv felhasznaloi azonos to alapjan a setuid bit csak
az e ektiv felhasznaloi azonos tot all tja { a valodi felhasznaloi azonos to is tarolva van
a processz-tablaban, amit a getuid() rendszerh vassal lekerdezhetunk vagy a setuid()
rendszerh vassal megvaltoztathatunk).
A setuid programok mindig zarjak le a megnyitott fajljaikat, mert a gyermekfolyamatkent vegrehajtott folyamatok a megnyitott fajlokat oroklik, es gy sok ertekes
informaciohoz juthatnak (mindegy, hogy miert - ennek lehet az oka programhiba is vagy
lehet akar egy ravasz rendszerprogramozo is).
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A programok altal hasznalt temporalis fajlokat ugy hozzuk letre, hogy azokra a tulajdonosuknak minden (esszer}) jogokat meg kell adni, m g masoknak ne legyen semmi
u
joguk a fajlra vonatkozoan (vagyis a 0700 oktalis szam gyakran megfelel a creat()-nel).
Mindig ellen}rizzuk a rendszerh vasok visszateresi erteket, es ha szukseges, az
o
errno valtozo erteket is. Ezzel kapcsolatban ismert a kovetkez} security-lyuk a UNIX
o
egy korabbi verziojaval kapcsolatban: barki rendszergazda jogokhoz juthatott egy kis
ugyesseggel, ugyanis a su parancsban volt egy oriasi hiba. Az su rendszerprogram olyan
esetben, amikor nem tudja megnyitni a jelszofajlt (neve /etc/passwd), jelszobekeres
nelkul rendszergazda jogokkal illeti meg a vegrehajtojat. A UNIX kesz t}i ugy gono
doltak, hogy a jelszofajl hianya olyan komoly problema { veletlenul nem is fordulhat
el} {, hogy ez a m}kodes elfogadhato. Viszont a su rendszerprogramban a jelszofajlt
o
u
megnyito open() rendszerh vas sikertelensegenek nem vizsgaltak meg az okat vagyis azt,
hogy valoban nem letezik-e a jelszofajl, vagy pedig mas oka van a fajlmegnyitas sikertelensegenek. Ezt a legtobben ugy jatszottak ki, hogy megnyitottak annyi fajlt, amennyit
csak lehetett1 , es vegrehajtottak a su parancsot. Ekkor az elind tott su parancs orokolte
az }t elind to folyamat megnyitott fajldeszkriptorait, de a jelszofajlt mar nem tudta mego
nyitni, mert nem volt szabad fajldeszkriptora: mar megnyitott annyi fajlt, amennyi a
folyamat szamara maximalisan engedelyezve volt. Igy tehat az open() rendszerh vas
sikertelen volt, annak ellenere, hogy volt egy olvashato jelszofajl, megis ugy tekintette a
rendszer, hogy "nagy baj van", es rendszergazda jogokkal ajandekozta meg az ovatlan
vegrehajtot
:::

1 Vagy kicsit kevesebbet .... persze vigyaztak arra, hogy a su utility be tudja kerni a jelszot a /dev/tty
fajlrol, es ehhez azt meg kellett tudnia nyitni. Itt megjegyezzuk, hogy a UNIX rendszerben statikus korlat az
egy folyamat altal egyidej}leg megnyithato fajlok szama.
u

Fejezet 7
A rendszermag szerkezete
Ebben a fejezetben attekintjuk az el}z} fejezetekben bemutatott rendszerszolgaltatasok
oo
implementalasat: azt, hogy milyen modon vannak implementalva a UNIX-szer} rendszu
erekben. Nyilvan tobb implementacio is letezik (System V, BSD, Linux, Solaris, ) es
mindegyik bemutatasara nincs lehet}seg (a forraskodban lehetnek nagyobb kulonbsegek
o
is), itt inkabb a fontosabb adatszerkezetek es a rendszerer}forrasok kapcsolatat es
o
kezelesmodjat fogom bemutatni. (Az el}fordulo peldak leginkabb a 4.3BSD rendszer
o
korai valtozataibol szarmaznak a memoriakezelesnel bemutatott regio rendszer pedig a
System V Release 3.0-bol szarmazik1.)
El}szor attekintjuk a folyamatokkezelesenek a fontosabb reszleteit, majd a hattereben
o
lev} memoriakezelesi mechanizmusokat valamint a fajlkezeles fontosabb kerdeseit fogjuk
o
tisztazni.
Meg kell eml teni, hogy a legtobb adatszerkezet a regebbi rendszermag implementaciokban statikus meret} volt (pl. egy x meret} vektorban voltak tarolva),
u
u
amit ma mar megprobalnak kikuszobolni, gy a rendszer maximalis mertekben kepes
lesz kieleg teni a valtozo er}forrasigenyeket. Azt, hogy egy tabla x meret}-e vagy
o
u
sem, itt nem fogom le rni (nem is rhatom), mivel ez egyreszt rendszermag implementacionkent valtozik masreszt pedig ugyanannak a rendszernek a kulonfele (peldaul
mas-mas gyartoktol szarmazo) valtozatai egyes reszletekben eltereseket mutathatnak
egymastol.
Nyilvanvaloan a kovetkez} pontokban le rt informaciok nem altalanos erveny}ek
o
u
(vagyis egy-egy rendszer implementaloja donthet ugy, hogy valamit mashogyan implemental), viszont az eddig elkeszult monolitikus operacios rendszer implementaciokban az
itt kozolt elveket kovetik a leggyakrabban.
A UNIX-szer} rendszerek forraskodjat eddig altalaban nagyreszt C nyelven
u
kesz tettek el a hardverfugg} reszek kivetelevel. A hardverfugg} reszeket pedig altalaban
o
o
alacsonyszint} assembly nyelven rjak (sorok szamat tekintve ez gyakran az egesz
u
rendszer meretenek az 5 szazaleka alatt van). A hardverfugg} reszek leginkabb az
o
eszkozmeghajtokat kezel}, valamint a memoriakezel} reszekben talalhatoak, m g ennel
o
o
kevesebb a hardverfugg} reszek mennyisege a folyamatok kezeleset vegz} komponenseko
o
ben, valamint a fajlrendszerkezel}ben.
o
:::

1 A bemutatott eszkozok kivalasztasanal els}sorban a szemleletesseg volt a celom, nem volt cel, hogy minden
o
eszkozt ugyanabbol az operacios rendszerb}l valasszak.
o
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7.1 A folyamatok kezelese
El}szor attekintjuk a folyamatok kezelesehez szukseges adatszerkezeteket, majd
o
megnezzuk azt, hogy milyen modon lehet az egyes folyamatkezel} rendszerh vasokat imo
plementalni.

7.1.1 A folyamatkezeles adatszerkezetei

Korabban mar eml tettem, hogy egy operacios rendszer megtervezesekor dont} szerepe
o
van annak, hogy mi minden kerul egy folyamatba { azaz milyen er}forrasok gy}jtemenye
o
u
a folyamat. Ez alapvet}en meghatarozza a rendszerben futo programok kornyezetet.
o
A legtobb rendszermag implementacio tartalmaz egy folyamatle ro adatszerkezetet,
amelyben osszegy}jtik egy-egy folyamat allapotanak az osszes jellemz}jet. Ez a folyau
o
matle ro adatszerkezet logikailag ket f} reszre bonthato: az egyik resz azokat az ino
formaciokat tartalmazza, amelyeknek minden id}pillanatban a memoriaban kell lenniuk
o
(ezt nevezik a System V, BSD rendszerekben proc strukturanak), m g a masik resz
(a user (felhasznaloi) struktura) azokat az informaciokat tartalmazza a folyamatrol,
amikre csak a rezidens allapotaban van szukseg (vagyis olyankor, amikor a folyamat
a zikai memoriaban tartozkodik, azaz a memoriakezel} nem rakta ki a hattertarra { a
o
zikai memoria kis merete miatt). A rendszer tartalmaz egy un. processz-tablat, amely
(gyakran x meret}) folyamatonkent tartalmaz egy hivatkozast a megfelel} folyamat
u
o
user illetve proc strukturajara, valamint tartalmazza egy egesz konstanst, ami a folyamat exit-statuszat es allapotat jellemzi, es a kovetkez} allapotok valamelyiket jelolheti
o
ki a folyamat aktualis allapotakent:
SSLEEP : A folyamat egy esemeny bekovetkeztere var (ld. kes}bb).
o
SRUN : A folyamat futasra kesz (lehet, hogy pillanatnyilag nem }, de az utemez}
o
o
atadhatja neki a vezerlest).
SZOMB : A folyamat befejez}dott, de a visszateresi erteket (exit-statuszat) meg
o
nem kerdezte meg a szul}je, ezert ez a processz-tabla bejegyzes meg nem lett
o
megszuntetve.
SSTOP : A folyamat futasa meg lett all tva (peldaul egy signallal).
SIDL : Egy segedallapot, amelyet a rendszermag letrehozas alatt allo, meg nem
futtathato folyamatok szamara tart fenn.
A proc struktura a kovetkez} informaciokat tartalmazza:
o
Utemezesi jellemz}k (peldaul a folyamat prioritasat), a folyamat processzortero
helesenek a merteket, ...
Folyamatazonos tot (a szul}folyamat azonos tojaval egyutt).
o
A folyamatot futtato felhasznalo azonos tojat.
Memoriakezelesi informaciok:
{ Egy hivatkozas a program kodjanak a szerkezetet le ro tablazatra (ezt nevezik
a BSD-ben text strukturanak { err}l nemsokara reszletesebben is rok).
o
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{ A folyamat laptablajanak a c met is tartalmazza.
{ A folyamat user strukturajanak a memoriabeli vagy (kilapozott allapotban)
hattertarolon lev} helyet tartalmazza.
o

Egy esemeny megnevezeset is tartalmazhatja, amelynek a bekovetkezeseig a folyamat varakozik (vagyis nem fut). A rendszermag egy-egy esemeny bekovetkeztekor
(peldaul amikor egy blokkot beolvasott a diszkr}l) megnezi azt, hogy mely folyamao
tok varakoznak az adott esemenyre, es tovabbind tja }ket. Egy folyamat egyszerre
o
legfeljebb csak egy esemeny bekovetkezesere varakozhat.
Tartalmazza azt, hogy milyen signalokat kuldtek a folyamatnak (ez lehet akar egy
32-bites egesz szam, egy-egy bitje egy-egy signalnak felelhet meg). Tovabba tartalmaz arrol is informaciokat, hogy az egyes signalokat a folyamat milyen modon
kezeli (nem veszi gyelembe oket, vagy van a folyamatban egy signal-kezel} eljaras,
}
o
vagy pedig az alapertelmezes szerinti signalkezelesi modot valasztotta a folyamat).
Amennyiben egy folyamat valamilyen esemenyre varakozas kozben signalokat kap,
akkor bejegyzi ide, hogy milyen signalt kapott, es a kapott signalt csak azutan fogja
feldolgozni, miutan az vart esemeny bekovetkezett, es a folyamat tovabbfut.
Tartalmazza, hogy a folyamat mikorra kert "ebreszt}t" (amennyiben onkent
o
varakozo allapotba ment valamennyi id} eltelteig, vagy egy ALARM signalt kert
o
az operacios rendszert}l).
o
A fenti adatok szerepe alapjan lathato, hogy allandoan a memoriaban kell }ket tartani
o
(ezek nelkul nem lehetne "igazsagosan" kivalasztani azt, hogy egy kontextuscsere utan
melyik folyamat kapja meg a processzort).
A folyamatok proc strukturaja egyreszt fel van f}zve egy ketiranyu listaba, amely
u
listan vegigmenve az osszes folyamat adataihoz hozzaferhetunk. Korabban mar
eml tettem, hogy egy folyamat tetsz}leges szamu utodot (gyermek-folyamatot) hozhat
o
letre, gy kialakulhat a folyamatoknak egy fa szerkezet} strukturaja, amely egy altalanos
u
fa (vagyis nem mondhatunk egy fels} korlatot arra vonatkozoan, hogy a faban egy folyamo
atot reprezentalo pontnak legfeljebb hany gyermeke lehet). Ezt a fa szerkezet} hierarchiat
u
is tarolni kell, amit a legtobb rendszerben nem kozvetlenul altalanos fakent tarolnak,
hanem az altalanos fa adatszerkezetet binaris fara visszavezetve taroljak (a binaris fara
valo visszavezeteses tarolas ugy tortenik, hogy a binaris fa minden egyes csomopontjaban
van egy hivatkozas az altalanos fabeli megfelel} pont els} gyermekere, valamint van egy
o
o
hivatkozas az altalanos fabeli testvereire { ez a modszer az adatszerkezeteket targyalo
konyvekben magtalalhato alapvet} modszer szamunkra ez mar kevesbe lenyeges).
o
Egy folyamat user strukturaja a kovetkez} informaciokat tartalmazza:
o
Tartalmazza azt, hogy a folyamat "felhasznaloi" uzemmodban fut-e, vagy pedig
valamilyen rendszerh vast vegrehajtva a rendszermag valamelyik reszeben "fut".
A rendszerh vasok parametereit es vegrehajtasuk allapotat le ro adatszerkezeteket.
A folyamathoz tartozo programvegrehajtasi pont jellemz}it (processzorregiszterek
o
erteket, a vegrehajtasi verem tetejere mutato veremmutato).
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A folyamathoz tartozo masodik (kernel modban hasznalt) veremmutato erteket
(egy folyamathoz leginkabb biztonsagossagi okok miatt ket verem tartozik: az
egyik vermet a program az eljarasok parametereinek, lokalis valtozoinak es a visszateresi c mek tarolasara hasznalja { erre szoktak egyszer}en vegrehajtasi verem
u
neven hivatkozni) a masik veremet a rendszermag olyankor hasznalja, amikor a
folyamat keresere valamilyen szolgaltatast elvegez (ezt nevezik a folyamat rendszermagbeli vermenek (angolul kernel stack), es a user struktura nemcsak a veremmutatot, hanem magat ezt a masodik (rendszermagbeli) vermet is tartalmazza. A
ket veremre els}sorban biztonsagi okok miatt van szukseg: egyreszt azzal, hogy a
o
( x meret} { nehany KB meret}) rendszermagbeli verem szamara szukseges (eleg
u
u
kicsi) hely allandoan le van foglalva, nem fordulhat el} az a kellemetlen helyzet,
o
hogy a rendszermag m}kodese soran "megbenul" egy esetleges memoriabeteles miu
att (ciki lenne, ha a rendszermag egy eljarast sem tudna megh vni, mivel mondjuk
betelt a memoria) tovabba mivel a folyamat "felhasznaloi" modban nem fer hozza
a rendszermagbeli vermenek a tartalmahoz, ezert nem tud hozzaferni a vermen lev}
o
olyan informaciokhoz, amit a kernel "rajta hagyott", es nem torolt onnan (ezekhez
az informaciokhoz a kernelen k vul masnak altalaban nincs semmi koze).
Itt van tarolva a folyamat fajldeszkriptoraihoz tarozo fajl-tablabeli hivatkozas
(vagyis az, hogy melyik fajldeszkriptorhoz a globalis fajltabla melyik eleme tartozik
{ emlekezzunk ra, hogy erre azert is szukseg van, mert egy folyamat "osztodasa"
utan a szul} es a gyermek folyamat ugyanazokhoz a fajlokhoz ferhet hozza, a
o
fajl-poz ciokat pedig megosztva hasznaljak). Itt vannak tarolva fajldeszkriptorhoz
kotott informaciok is (peldaul az, hogy a fajlt a folyamat "osztodasa" utan automatikusan le kell zarni).
A folyamat er}forrashasznalatanak jellemz} adatai (azaz mib}l mennyit hasznalt
o
o
o
(CPU id}t)).
o
A folyamatot futtato felhasznalo csoport-azonos toja, valamint az e ektiv felhasznaloi es csoportazonos tok is itt lesznek tarolva.
A folyamat munka-directoryja is itt van tarolva.
A folyamat gyoker-directoryja is itt van tarolva (ne felejtsuk el, hogy ez is valtozhat
{ gondoljunk csak a chroot() rendszerh vasra).

Egy folyamat a memoriaban tobb un. szegmensb}l all (egyes implementaciokban a
o
szegmens helyett a regio elnevezest is hasznaljak). A szegmenseknek harom "osztalyat"
szokas megkulonboztetni (ez az osztalyozas a szegmensek szerepe alapjan tortenik): vannak vegrehajthato utas tasokat tartalmazo un. kodszegmensek, adatokat tartalmazo
adatszegmensek, valamint a vegrehajtasi vermet tartalmazo veremszegmensek. Egy
folyamat altalaban mindharom szegmenst pussal rendelkezik a szegmenseket a virtualis
memoriaban ugy szokas elhelyezni, hogy a virtualis c mtartomany valamelyik "vegen"
(leggyakrabban az aljan) helyezkedik el a x meret} kodszegmens (ennek a merete adott,
u
miutan a programot leford tottuk), a fennmarado helyen pedig a verem es az adatszegmens helyezkedik el { altalaban ezek nem rogz tett meret}ek, kezdetben a virtualis
u
c mtartomany ket "szelen" helyezkednek el, es egymas iranyaba h znak. A szegmensek
altalaban egy szegmenstablaba vannak rendszerezve.
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Mar eml tettem, hogy minden folyamathoz nyilvan van tartva egy hivatkozas egy un.
strukturara. Ez a text struktura pointereket tartalmaz a folyamat vegrehajthato
kodjat tartalmazo kodszegmensekre. Minden text struktura tartalmaz egy referenciaszamlalot (ez egy egesz szam), amelyben tarolja, hogy hany folyamat hivatkozik
ra a proc strukturajaban (vagyis az altala le rt vegrehajthato kodot hany program
hasznalja)), valamint tartalmazza a ra hivatkozo folyamatok proc strukturajanak a
listajat.
text

7.1.2 A folyamatkezeles rendszerh vasai

Mar lattuk a folyamatok szerkezetenek a kezelesevel kapcsolatos fontosabb adatszerkezeteket most attekintjuk azt, hogy a folyamatokat kezel} rendszerh vasok (peldaul a
o
fork() es az exec()) (illetve a wait() es az exit()) hogyan lesznek megvalos tva, mit
kell csinalniuk ezeken az adatszerkezeteken a feladatuk elvegzeseert.
A fork() rendszerh vas letrehoz egy uj proc struktura objektumot az uj gyermekfolyamat reszere es megfelel}en kitolti azt (egyedi folyamatazonos tot kap, bejegyzi a futo
tato felhasznalo azonos tojat, ). Ezutan a szul} folyamat user strukturajat lemasolja,
o
es a masolatot az uj folyamat megkapja. Mivel mind a szul}, mind pedig a gyermek folyao
mat ugyanazt a kodot hajtja vegre (mindkett}nek a proc strukturaja ugyanarra a text
o
strukturara mutat), ezert a szul} text strukturajanak a referenciaszamlalojat novelni
o
kell eggyel a konzisztencia erdekeben, es az ujonnan letrehozott folyamat proc strukturajat be kell csatolni a folyamatok korabban mar eml tett ketiranyu listajaba illetve
a folyamatok fa-strukturaju hierarchiajaba. Ezutan az adat- illetve veremszegmensek
szamara lesz hely lefoglalva (pontosan akkora, amekkora a szul}ben volt a megfelel}
o
o
szegmens merete), es a szul} adat- illetve veremszegmensenek a tartalma at lesz masolva
o
a gyermekfolyamat megfelel} szegmenseibe. Megjegyezzuk, hogy ezt a szegmensmasolast
o
gyakran optimalizaljak olymodon, hogy a gyermek es a szul} folyamatok ugyanazt a
o
memoriat hasznaljak egeszen addig, ami g valamelyikuk nem modos tja, es a tenyleges
masolasra csak a modos taskor (altalaban csak a modos tott reszt tartalmazo lapon) kerul
sor. Ez az optimalizalas a fork() m}veletet nagyon "olcsova" teheti a legtobb alkau
lmazasakor, mivel a fork() szolgaltatast hasznalo programok nagyon nagy szazalekaban
a fork() rendszerh vast egy exec() rendszerh vas koveti a gyermekfolyamatban, aminek
az eredmenyekent a folyamat virtualis c mtartomanyanak a kod-, adat- illetve veremszegmenset ki lehet dobni ... Termeszetesen a processz-tablaban is letrejon egy uj bejegyzes a
megfelel} proc illetve user strukturakkal, a folyamat pedig futasra kesz SRUN allapotban
o
lesz bejegyezve.
Az exec() rendszerh vas nem hoz letre uj proc illetve user strukturat, hanem az
ujonnan elind tando folyamat kodjat tartalmazo kodszegmenssel egy uj text strukturat
hoz letre (ha a megfelel} kodszegmenst tartalmazo text struktura mar letezik, akkor
o
annak a referenciaszamlalojat noveli eggyel), a regi kodot tartalmazo text struktura
referenciaszamlalojat pedig csokkenti eggyel, es amennyiben a szamlalo nullara csokken
(vagyis mas mar nem hasznalja azt a kodot), akkor az operacios rendszer eldobja azt.
A vegrehajthato programbol be lesznek toltve az inicializalt statikus illetve globalis
valtozokat tartalmazo adatszegmens (ha van ilyen). A fajldeszkriptor tabla olyankor
modos tva lesz, ha valamelyik fajldeszkriptorhoz megadtak, hogy exec() rendszerh vas
vegrehajtasakor le kell zarni. A signalok kezeleset le ro tablazatok majdnem minden
valtoztatas nelkul megmaradnak, csak olyankor kell modos tani, ha valamelyik signal:::
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hoz egy signal-kezel} eljaras c me volt eltarolva, ugyanis az ujonnan betoltott folyamat
o
c mtartomanyaban ki tudja mi van azon a helyen .
Miutat egy folyamat befejez}dik es vegrehajtotta az exit() rendszerh vast, a kero
nel felszabad tja az altala lefoglalt adat es verem memoriaszegmenseket, csokkenti a
kodszegmenst le ro text struktura referenciaszamlalojat, es ha ez nullara csokken, akkor
felszabad tja a kodszegmensek altal elfoglalt memoriateruleteket. Ezutan lezarja a befejez}dott folyamat meg megnyitott fajldeszkriptorjait, es deallokalhatja a user struko
turajat is. A folyamat exit-statusza (vagyis az az ertek, amit az exit() rendszerh vas
argumentumakent megadtak, ki lesz masolva a proc strukturabol (ui. kicsivel korabban
oda lett berakva) a processz-tablaba, majd a szul}folyamatnak kuldve lesz egy SIGCHLD
o
signal, jelezve neki, hogy meghalt egy gyermeke, ezutan deallokalva lesz a folyamat proc
strukturaja. A gyermek ezutan { mar er}forrasait felszabad tva { bekerul a zombie
o
folyamatok (processz-tablabeli allapota SZOMB lesz) koze egeszen addig, am g a szul}je le
o
nem kerdezi az exit-statuszat, majd utana a folyamat processz-tabla bejegyzese is torolve
lesz.
A wait() rendszerh vas vegrehajtasa utan a szul} folyamat megnezi a gyermekeinek
o
a listajat, hogy valamelyik befejez}dott-e (azaz allapota SZOMB-e), es ha igen, akkor
o
visszaadja az exit-statuszat, es megszunteti a szamara lefoglalt processz-tabla bejegyzest.
:::

7.1.3 Utemezesi kerdesek

A rendszermag feladatai koze tartozik az utemezes megszervezese: a processzor
megosztasa a futasra kesz folyamatok kozott { lehet}leg igazsagosan (az igazsagossag nem
o
feltetlenul az egyenl} elosztast jelenti, hanem a folyamatok kozt a fontossaguk szerinti
o
elosztast). A kontextuscsere (vagyis a valtas az egyik folyamatrol a masikra) vagy akkor
lesz, amikor az aktualisan futo folyamat id}szelete lejar (vagyis mondjuk 50 ms-on at fuo
tott), vagy amikor a folyamat valamilyen I/O m}velet elvegzeset keri a rendszermagtol,
u
es a folyamat kenytelen leallni es varakozni addig, am g a rendszermag a megadott
m}veletet elvegzi. Fontos megeml teni, hogy amikor egy folyamat a rendszermag valamiu
lyen szolgaltatasat igenybe akarja venni, es a vezerles atadodik a rendszermagba, azutan
a rendszermagban futo folyamat nem lesz megszak tva (vagyis nem tortenik kontextuscsere) egeszen addig, am g a folyamat vagy el nem hagyja a rendszermagot, vagy pedig
onmaga hajlando lemondani a CPU-hasznalati jogarol (altalaban azert, mert valamilyen
esemenyre kell varnia). Erre azert van szukseg, mert a rendszermag szolgaltatasait egyszerre tobb folyamat is igenyelheti, es valamilyen modon meg kellett valos tani a konkurrens folyamatok kolcsonos kizarasat. Az eleg drasztikus megoldasnak tunhet, hogy a
rendszermag hasznalata kozben a folyamatok nem szak thatok meg, viszont a rendszermag altalaban ugy van elkesz tve, hogy a folyamatok viszonylag hamar kilephetnek
bel}le vagy eleg hamar kenytelenek onszantukbol a CPU-hasznalati jogot (pl. egy I/O
o
eszkoznek munkat adva).
Amikor egy folyamat a rendszermagban tartozkodik, es kezdemenyezi egy diszkszektor tartalmanak a beolvasasat, akkor varnia kell addig, am g a megadott szektor
be lesz olvasva a kozponti memoriaba, es a rendszermag a rendelkezesere bocsatja a
megadott blokkot. Ezt a varakozast a folyamat eltoltheti ugy is, hogy folyamatosan
vegrehajt olyan utas tasokat, amelyekkel ellen}rizheti, hogy a rendelkezesere all-e a
o
megadott diszk-szektor, es ha nem, akkor tovabb var, viszont ez a megoldas CPUid} pazarlashoz vezetne, hiszen azalatt, am g egy folyamat varakozik, addig egy masik
o
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folyamatot el lehet ind tani (ez az id}osztasos multiprogramozas hatekonysaganak talan
o
legf}bb alapja). Egy folyamat a rendszermagban a sleep() fuggvenyh vassal mondhat le
o
a processzorhasznalati jogarol (ennek a fuggvenynek az argumentumakent meg kell adni
egy esemeny-azonos tot { annak az esemenynek az azonos tojat, aminek a bekovetkezeseig
a folyamat varakozni akar). Amikor egy esemeny bekovetkezik (peldaul beolvastak
egy olyan diszk-szektort, amire valamelyik folyamat varakozik), akkor aki az esemenyt
el}idezte (diszk-blokk beolvasaskor peldaul az az eszkozmeghajto, amelyik a kerdeses
o
blokkot beolvasta) vegrehajt egy wakeup() fuggvenyh vast, megadva az argumentumakent a bekovetkezett esemeny azonos tojat, es ezutan az osszes olyan folyamat, amelyik
a megadott esemenyre varakozott ujra futasra keszen varja, hogy megkapja a kovetkez}
o
id}szeletet. Fontos latni, hogy egy esemenyre egyidej}leg tobb folyamat is varakozhat, es
o
u
ha egy esemeny bekovetkezik, akkor az osszes ra varo folyamat tovabb fog futni (ez azt
is jelenti, hogy ha peldaul memoriahiany eseten ket folyamatnak is szuksege van mondjuk egy-egy szabad memorialapra, akkor mindketten varakozhatnak arra az esemenyre,
hogy felszabadul egy korabban hasznalatban lev} memorialap, es miutan felszabadult
o
egy memorialap, akkor mindket varakozo folyamat el lesz ind tva, viszont miutan az
egyik folyamat { mondjuk az, amelyik el}bb fut { megszerezte maganak a felszabadult
o
memorialapot, ismet el}all az a helyzet, hogy nincs szabad memorialap, es a masik {
o
addig varakozo { folyamat ezt ellen}rizven ujbol varakozasra kenyszerul). Felmerulhet a
o
kerdes, hogy hogyan nevezhetik az esemenyeket, amiknek a bekovetkezesere varni lehet:
tetsz}leges egesz szam megadhato esemenynevkent, de a kialakult konvenciok alapjan
o
egy, az esemennyel kapcsolatos fontosabb, az esemenyt egyertelm}en azonos to rendu
szermagbeli adatszerkezet memoriabeli c met szokas esemeny-azonos tokent megadni:
ha peldaul egy adott sorszamu diszk-szektor beolvasasara varunk, akkor megadhatjuk
annak a memoriarekesznek a c met esemenyazonos tokent, ahova a megadott diszkblokk beolvasasat a kernelt}l kertuk (a megfelel} diszk-blokk bu er fejlecenek a c met
o
o
{ ld. err}l a kes}bbieket). A rendszermag sleep/wakeup mechanizmusanak van egy
o
o
hatranya is: a sleep m}velet nem egyetlen atomi gepi utas tas vegrehajtasabol all, ezert
u
el}fordulhat az, hogy az esemeny bekovetkezeset jelz} wakeup-ot az esemenyt el}idez}
o
o
o o
rendszermagkomponens a sleep m}velet befejez}dese el}tt megh vja, es mivel akkor meg
u
o
o
az van nyilvantartva, hogy senki nem var az adott esemenyre, ezert a wakeup nem
jelzi az epp varakozni kezd} folyamatnak, hogy nem kell tovabb varakoznia. Ezt a
o
problemat ugy oldottak meg, hogy az ilyen kritikus helyzetekben az ellen}rzest vegz}
o
o
kodot es a sleep fuggvenyh vast "mestersegesen" atomi utas tassa teszik azzal, hogy a
vegrehajtasuk idejere letiltjak a hardver megszak tasokat (ezzel senki sem szak thatja
felbe a m}kodeset).
u

7.2 A memoriakezel} implementacioja
o
A memoriakezeles feladata a rendszermag memoriaszuksegleteinek a kieleg tese. Ez
nyilvan magaba foglalja a a folyamatokat alkoto szegmensek ill. regiok szamara valo
helylefoglalast, valamint az operacios rendszer bels} feladatainak ellatasahoz szukseges
o
memorialefoglalast. Lathattuk, hogy a kernel verem merete x, raadasul nem is tul
nagy, ezert azon nem lehet nagymeret} lokalis valtozokat allokalni { ezert a kernel
u
rakenyszerulhet arra, hogy mas forrasokbol jusson a feladatanak az ellatasahoz szukseges
memoriahoz.
A memoriakezel} ket f} komponensb}l all: az egyik komponens feladata az
o
o
o
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el}bbiekben mar megeml tett regio t pusu objektumok implementalasa a processzor
o
memoriakezel} hardveren (ez proceszort pustol fugg} kod a kulonboz} gyartmanyu,
o
o
o
de azonos processzoru gepek kozott ez egy hordozhato kodnak tekinthet} { ennek
o
kell biztos tani a rendszermag lapozasos es szegmentalt memoriakezelesenek az alapjait). A masik komponens feladata a regio objektumok seg tsegevel a rendszermag
memoriaigenyeinek a kieleg tese.
Mint mar eml tettem, egy folyamat virtualis memoriaja kulonfele un. regiokbol lesz
osszerakva. Letrehozasakor egy folyamat virtualis c mtartomanya negy regiot tartalmaz:
Egy vegrehajthato kodot tartalmazo regiot
Egy, az inicializalt (kezd}ertekekkel ellatott) globalis valtozokat tartalmazo regiot
o
Egy, az inicializalatlan (kezd}ertekekkel nem ellatott) valtozokat tartalmazo regiot
o
(ez a regio nem x meret} a merete a folyamat igenyeinek megfelel}en b}v thet}
u
o o
o
vagy csokkenthet}). A program futasa soran allokalt dinamikus memoria (C
o
programokban peldaul a malloc() fuggvenyh vassal torten} memoriaallokalassal
o
lefoglalt memoria) ebben a regioban lesz lefoglalva.
A vegrehajtasi vermet tartalmazo regiot.
Egy regio merete tehat id}ben valtozhat, es meretukkel kapcsolatban egyetlen korlat
o
az az, hogy a regioknak be kell ferniuk a (virtualis) memoriaba.
Egy folyamathoz id}vel ujabb regiokat is lehet allokalni: peldaul osztott konyvtarak
o
(shared library) alkalmazasakor egy osztott konyvtar betoltese egy ujabb programkodot,
valamint egy ujabb inicializalt adatokat tartalmazo regio letrehozasat jelenti az osztott
konyvtarat alkalmazo folyamat virtualis c mtartomanyaban.
Megjegyezzuk, hogy az itt bemutatott regio modell nagyon hasonl t az AT&T UNIX
System V Release 3.0 operacios rendszereben alkalmazott megoldasra (ott nevezik a
memoria alotoelemeit regioknak) { igaz nehany helyen az egyszer}bb targyalas erdekeben
u
kis modos tasokat vegeztem.

7.2.1 A regiom}veletek
u

Ebben a pontban roviden osszefoglalom a regio objektumokon vegezhet} m}veleteket:
o u
Egy uj (ures) regio lefoglalasa.
Egy regio objektum megszuntetese.
Egy regio tartalmanak beagyazasa egy folyamat virtualis c mtartomanyaba.
Egy regio lecsatolasa egy folyamat virtualis c mtartomanyabol.
Egy regiorol masolat kesz tese.
Egy regio meretenek a modos tasa.
A fajlrendszerb}l egy program betoltese egy regioba.
o
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Egy regio rogz tese a zikai memoriaba I/O m}veletek idejere, illetve a rogz tes
u
megszuntetese (erre azert lehet szukseg, mert az intelligens diszk-kontrollerek a
rajuk b zott feladatot (pl. egy diszk-blokk beolvasasa) a "hatterben" is el tudjak
vegezni, es meg kell akadalyozni azt, hogy egy olyan lapot kilapozzanak, amire egy
ilyen intelligens diszk-kontrollert}l adatokat varunk (ui. a legtobb diszk-kontroller
o
ezt nem tudja "kovetni", es amikor beolvassa az adatokat, akkor mar nem oda kell
beolvasni, amit korabban megadtak).

7.2.2 A regio rendszer adatszerkezetei

A processz-tabla (valamint a text struktura) tartalmazza egy regiolista c met. Egy ilyen
regiolista egy eleme egy-egy folyamat virtualis memoriajat alkoto memoriateruleteket
(regiokat) le ro regiole ro strukturara mutat. Egy adott regio le ro strukturajara tobb
folyamat regiolistajarol is mutathat egy-egy pointer { ha az adott regio tobb folyamat
virtualis c mtartomanyanak is resze. A folyamatonkent nyilvantartott regiole ro lista
tartalmazza azt is, hogy egy adott regio a folyamat c mtartomanyaban hol helyezkedik
el, gy egy adott regio nem kell, hogy az osszes folyamat virtualis c mtartomanyaban
ugyanott helyezkedjen el.
Egy regiole ro objektum tartalmaz egy hivatkozast a regio tartalmat le ro
memorialapok sorozatat le ro "laptablara". Egy "laptabla" ket fontos komponensadatszerkezete a kovetkez}: a hardver memoriakezel} egysegenek a laptablaja (a
o
o
hardver memoriakezel} egysege altal el} rt formaban), valamint tartalmazza azoko
o
nak a magneslemez-szektorok c menek a sorozatat, ahova az adott regio tartalmat
ki lehet lapozni memoriasz}ke eseten (ezzel a virtualis memoria meretet a virtualis
u
memoriakezeles szamara fenntartott lemezterulet meretere korlatozza { de ez mar implementacios reszlet, amit mashogyan megoldva mas korlatozasokhoz juthatunk, illetve
kell}en exibilis megoldast talalva kikerulhetjuk a korlatozasokat).
o
Egy regio el van latva egy t pus-azonos toval, amely t pus-azonos to a regio hasznalati
modjarol adhat tovabbi informaciokat. Egy regiot pus-azonos to egy konstans, melynek
az erteke a kovetkez} konstansok kozul kerulhet ki:
o
: Programkodot tartalmazo, nem modos thato tartalmu, tobb folyamat altal is elerhet} regio.
o

SHARED TEXT

SHARED MEMORY

: Adatokat tartalmazo, tobb folyamat altal is elerhet} regio.
o

: Egy folyamat sajat (mas folyamatokkal nem megosztott) adatait tartalmazo regio.
PRIVATE

Egy uj folyamat letrehozasakor a virtualis memoriajat alkoto regiokat le ro lista le lesz
masolva. Ekkor a PRIVATE t pusu regioknak egy uj peldanya lesz letrehozva (atmasolva
az eredeti regio tartalmat), a tobb folyamat altal megosztottan hasznalt regiokra uj hivatkozasok lesznek letrehozva. Egy folyamat megszuntetesekor azok a regiok meg lesznek
szuntetve, amelyekre csak az az egy folyamat hivatkozik (vagyis a megszunteten} folyao
mat hivatkozik ra, es csak egy folyamat hivatkozik ra).
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7.2.3 A lapozas implementalasa

A zikai memoriat a rendszermag implementaciok altalaban harom f} reszre bontjak: az
o
egyik resz a magat a rendszermagot a kod illetve adatszegmenseivel egyutt tartalmazo
resz a masik resz a zikai memoria lapkereteir}l nyilvantartott informaciokat tartalo
mazza (ez a memoriaterkep { eredeti angol neven core map) a harmadik reszt pedig
maguk a zikai memoriaban lev} lapkeretek alkotjak. A rendszermag eddig elkeszult
o
implementacioinak kozos jellemz}je, hogy a rendszermagnak es a core mapnak teljes
o
egeszeben allandoan a zikai memoriaban kell lennie, azaz nem lapozhato ki.
A lapozas implementaciojanak a kozponti adatszerkezete az el}bb mar eml tett core
o
map. A core map minden egyes zikai memoriaban lev} lapkerettel kapcsolatban nyo
ilvantartja, hogy az adott lapkereten lev} lap a virtualis memoriat tartalmazo diszken
o
hol helyezkedik el (akkor, ha nincs a memoriaban), azaz hova kell majd kilapozni a core
map tarolja azt is, hogy az adott lapkereten lev} lap melyik regionak a resze azt is
o
tarolja, hogy a lap a r'egion belul hanyadik lap. Ezenk vul a core map az eppen nem
hasznalt (szabad) lapkereteket egy listaba f}zi, valamint minden egyes lapkerethez tarolja
u
azt is, hogy az a lapkeret eppen szabad-e, valamint azt, hogy az adott lapkeret tartalmat
nem szabad kilapozni a hattertarra (mivel peldaul egy I/O m}velet a hatterben dolgozik
u
rajta). Megjegyezzuk, hogy a core map lapkeretenkent egy x meret} adatszerkezet: a
u
Berkeley UNIX-ban egy core map bejegyzes merete 16 bajt { ennyi plusz informaciot kell
tarolni a lapozas megszervezesehez minden egyes 4096-bajtos lapkerethez (vagyis ezzel a
memorianak kevesebb, mint az egy szazaleka "veszik el").
A lapozast a rendszermag es egy felhasznaloi uzemmodban futo folyamat (a lapozo
daemon) egyuttesen implementaljak. A rendszermag tarolja a szabad lapkeretek szamat,
es ha a szabad lapkeretek szama egy kuszobertek alatt van (pl. az osszes lapkeretek
szamanak a harminc szazalekat nem eri el), akkor a lapozo demon a core mapben tarolt
informaciok alapjan felszabad t ujabb lapkereteket. A lapcsere algoritmuskent az ora (ez
lenyegeben FIFO) algoritmushoz hasonlo ketmutatos ora algoritmust alkalmazzak. Az
ora algoritmus onnan kapta a nevet, hogy modellezheto egy ora mutatojaval, amely
"vegighalad" a core map-bejegyzeseken, es az osszes nem szabad, es kilapozas ellen
nem vedett lapot kilapozhatonak nyilvan tja, ha pedig egy lapot az el}z} menetben
oo
kilapozhatonak nyilvan tott, es az el}z} menet ota nem volt ra hivatkozas, akkor ki is
oo
lapozza. A ketmutatos ora algoritmusban az oranak ket "mutatoja" van: az egyik mutato a masikat valamekkora (pl. a memoria 25 szazalekanak megfelel}) rest kihagyva
o
koveti, es az el}l lev} mutato altal mutatott, nem szabad es kilapozas ellen nem vedett
o o
lapot kilapozhatonak nyilvan tja a rendszer, majd amikor az ora masodik mutatoja egy
kilapozhatonak nyilvan tott, es azota nem hasznalt lakeretet talal, akkor a megfelel} lapo
keret tartalmat kilapozza a hattertarra. Vagyis az egy- illetve ketmutatoju ora algoritmus
lenyegeben ugyanaz, csak egy lap kilapozhatova nyilvan tasa es a kilapozasa kozott eltelt
id} ket mutatos esetben kisebbe tehet}.
o
o

7.2.4 A programbetoltes

Amikor egy folyamat vegrehajt egy exec() rendszerh vast, akkor ellen}rzi azt, hogy a
o
megadott vegrehajtando fajl valoban vegrehajtato-e (azaz a hozza tartozo rwx-bitek kozt
megvan-e a megfelel} x bit, valamint a kernel ellen}rzi a vegrehajthato fajlokra vonatkozo
o
o
nehany formai kovetelmeny teljesuleset). Ha vegrehajthato, akkor betolti az egyes
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logikai reszeit a memoriaba (letrehozva a szukseges regiokat a memoriaban - lapozasos
memoriekezel}vel ellatott operacios rendszerek eseteben gyakori a futo programoknak
o
az "igeny szerinti" belapozasa, azaz a hattertarrol csak azok a lapok lesznek belapozva,
amelyekre rakerul a vezerles, es csak akkor lesznek belapozva, amikor szukseg lesz rajuk),
es ha minden problemamentesen sikerut, akkor a folyamat korabbi c mtartomanyat eldobja (az azt le ro regiok kozul megszunteti azokat, amelyekre mas folyamatok nem hivatkoznak), es az ujonnan beolvasott regiokat jeloli ki a folyamat vegrehajthato kodjat,
adatait illetve vegrehajtasi vermet tartalmazo regiokent, es elkezdi az uj kodszegmens
vegrehajtasat az "elejet}l". Nyilvan ha az uj regiok betoltese sikertelen (peldaul mert
o
elfogyott a memoria), akkor a betoltott uj regiokat el kell dobni, es az exec() rendszerh vas hibakoddal kell, hogy visszaterjen. Ezert az nem jo megoldas, hogy a korabbi
kod, adat illetve verem szegmenseket mindjart a rendszerh vas megkezdesekor kidobjuk,
mert lehet, hogy nem tudjuk az uj regiokat a diszkr}l beolvasni.
o
A vegrehajthato fajlokra vonatkozo egyetlen formai kovetelmeny { az hagyomanyos
un. a.out2 fajlformatum eseten { az, hogy a fajl elejen kell lennie egy fejlecnek, ami
terkepkent tartalmazza az egyes szegmensek helyet a vegrehajthato programot tartalmazo fajlon belul. E fejlec szerkezete a kovetkez} C nyelv} strukturaval jellemezhet}:
o
u
o
struct a_out_fejlec {
unsigned long a_magic
unsigned long a_text
unsigned long a_data
unsigned long a_bss
unsigned long a_syms
unsigned long a_entry
unsigned long a_trsize
unsigned long a_drsize
}

7.3 Az eszkozmeghajtok implementacioja
A rendszermag a kulonfele hardver periferiakkal foglalkozo reszeket egy { a gepfugg}sege
o
miatt { jol elkulon thet} modulban tartalmazza: az eszkozmeghatjtok moduljaban. A
o
legtobb rendszermag implementacio az eszkozoket (illetve az eszkozok vezerleseert felel}s
o
rendszermagreszeket, az eszkozmeghajtokat) ket csoportba osztja: a karakteres eleres}
u
es a blokkonkenti eleres} eszkozok csoportjara.
u
Ha a rendszerhez egy uj eszkozt akarunk illeszteni, akkor meg kell rni az eszkoz
vezerleseert felel}s eszkozmeghajtot (ez nehany jol de nialt, az eszkozzel kapcsolatot
o
tarto eljaras meg rasat jelenti), es a meg rt eljarasokat egy, az eszkozmeghajto eljarasokat
tartalmazo, globalis vektorba be kell tenni (a karakteres eszkozok eseten e vektor neve
cdevsw, a blokkos eleres} eszkozok eseten pedig bdevsw). Egy eszkoz major device
u
numberje az e vektorokon beluli indexevel egyenl}.
o
2 Van tobb ismert vegrehajthato-fajl formatum (mint peldaul az a.out, x.out, COFF, ELF), amelyeknek
hsonlo a szerepe, de nehany extra lehet}seg megleteben kulonboznek egymastol. Ebben a le rasban az un.
o
a.out fajlformatumot, a legregebb ota hasznalt vegrehajthato-fajl formatumot fogjuk megismerni. Ez megfelel
a szokasos rendszermag-implementaciok igenyeinek, es konny} is megerteni.
u
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A blokk-eleres} eszkozoket meghajto eszkozmeghajto a kovetkez} eljarasokat mint
u
o
belepesi pontokat tartalmazza:
: A rendszer ind tasakor lesz vegrehajtva, feladata az eszkoz pontos
azonos tasa.
init()

: Ez az eljaras az eszkozmeghajtohoz tartozo specialis fajlra vonatkozoan
kiadott open() rendszerh vas hatasara lesz vegrehajtva. Altalaban ellen}riznie kell,
o
hogy a hozza tartozo hardver periferia a rendszer ind tasakor helyesen fel lett-e
ismerve, illetve m}kodik-e.
u
open()

: Ez az eljaras akkor lesz vegrehajtva, ha az eszkozt hasznalo osszes folyamat az eszkozre vonatkozoan korabban megnyitott specialis fajlt lezarta. Ilyenkor
az eszkozmeghajtot es az eszkozt egy "alapallapotba" kell hozni. Peldaul ezt
hasznaljak magnesszalagok visszatekeresere, miutan mar senki sem hasznalja (igaz,
ritka a blokk eleres} magnesszalagegyseg).
u
close()

: Egy eszkozre valo rasi vagy az eszkozr}l torten} olvasasi m}velet
o
o
u
kezdemenyezeset lehet vele kerni. Argumentumakent meg kell adni egy diszkblokk bu er fejlecenek a c met (ld. reszletesebben a bu er cache le rasakor), es
a h vo folyamat a bu er fejlecenek a c met mint esemenyazonos tot hasznalhatja,
ha varakozni akar az I/O m}velet befejez}desere (amit az eszkozmeghajto tobbi
u
o
resze (pl. interrupt-vezerelten) megold).
strategy()

: Eszkozfugg} m}veleteket lehet ebbe berakni. Az eszkozhoz tartozo
o u
specialis fajlra vonatkozoan kiadott ioctl() h vaskor lesz vegrehajtva. Egy
diszk eseteben itt implementalhatok peldaul a diszk meta-informacioinak (meret,
part cios tabla) a lekerdezesenek es beall tasanak a m}veletei.
u
ioctl()

A karakteres eleres} eszkozoket meghajto eszkozmeghajto a kovetkez} eljarasokat
u
o
mint belepesi pontokat tartalmazza:
: A rendszer ind tasakor lesz vegrehajtva, feladata az eszkoz pontos
azonos tasa.
init()

: Ez az eljaras az eszkozmeghajtohoz tartozo specialis fajlra vonatkozoan
kiadott open() rendszerh vas hatasara lesz vegrehajtva. Altalaban ellen}riznie kell,
o
hogy a hozza tartozo hardver periferia a rendszer ind tasakor helyesen fel lett-e
ismerve, illetve m}kodik-e.
u
open()

: Ez az eljaras akkor lesz vegrehajtva, ha az eszkozt hasznalo osszes folyamat az eszkozre vonatkozoan korabban megnyitott specialis fajlt lezarta. Ilyenkor
az eszkozmeghajtot es az eszkozt egy "alapallapotba" kell hozni. Peldaul ezt
hasznaljak magnesszalagok visszatekeresere, miutan mar senki sem hasznalja.
close()

read()

: Karaktereket olvas be az adott eszkozr}l.
o

write()

: Karaktereket r az adott eszkozre.
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: Eszkozfugg} m}veleteket lehet ebbe berakni. Az eszkozhoz tartozo
o u
specialis fajlra vonatkozoan kiadott ioctl() h vaskor lesz vegrehajtva. Egy
magnesszalag eseteben itt implementalhatok peldaul a szalagvege karakter fel rasa
a szalagra, valamint a szalag meta-informacioinak (meret, part cios tabla) a
lekerdezesenek es beall tasanak a m}veletei.
u
select() : Ellen}rzi, hogy van-e beolvasni valo adat az eszkozr}l illetve ellen}rzi,
o
o
o
hogy van-e hely az eszkozon, ahova uj adatokat lehet fel rni.
stop() : Ezt megh vva lehet szuneteltetni egy eszkozre a karakterek kiiratasata
(peldaul egy terminalon a ctrl-S karakterek megnyomasakor szunetelni fog a ki ras).
ioctl()

A rendszermag forraskodjanak a leford tasakor gyakran tobb eszkozmeghajtot beford tanak, mint amennyire tenylegesen szukseges lenne. A rendszermagba beford tott
eszkozmeghajtokat ugy nevezik, hogy statikusan bekon guralt eszkozmeghajtok. A rendszer beind tasakor az osszes statikusan bekon guralt eszkozmeghajto init() vegre lesz
hajtva, es ekkor ellen}rzi a kernel, hogy az eszkoz hozza van-e kapcsolva a gephez,
o
lekerdezi a harver parametereit, stb. Ezt a folyamatot nevezik autokon guracionak.

7.4 A bu er cache szerepe es implementacioja
A blokk eleres} eszkozok kezeleset vegz} eszkozmeghajtok es a gepfuggetlen "magau
o
sszint}" rendszermag kozott helyezkedik el egy szoftverreteg, a bu er cache. A bu er
u
cache un. bu er objektumokat kezel: egy bu er egy diszk-blokk (illetve mas blokk
eleres} eszkozok "blokkjainak") tartalmat tartalmazza, es a legfontosabb celja az, hogy
u
az adott blokkot hasznalo illetve modos to osszes folyamat ugyanazon a "peldanyon" dolgozzanak (vagyis ha az egyik folyamat megvaltoztatja egy blokk bu er tartalmat, akkor
az osszes tobbi parhuzamosan futo es ugyanazt a blokkot hasznalo folyamat azonnal a
modos tott diszk-blokk tartalmat lassa). Vagyis az osszes folyamat egy adott diszk-blokk
tartalmat a rendszerben csak es kizarolag a rendszer memoriajaban egyetlen peldanyban
tarolt blokk-bu eren keresztul erheti el. E bu erelesnek egy kovetkezmenye az is, hogy
a gyakran hasznalt diszk-blokkok a memoriaban lesznek tarolva, ezzel meggyors tva a
diszk-blokkhoz valo hozzaferest (es mivel a memoriaban tarolt diszk-blokk tartalmat
hatekonysagi okok miatt csak kesleltetve rja fel a diszkre, ezert a rendszer erzekennye
valik az aramkimaradasokra { ez onmagaban egy hatrany, de a bu ereles tobb el}nye
o
miatt altalaban nem tekintik nagy problemanak).
A bu er cache kulcsfontossagu objektumai a bu er fejlecek, es a hozzajuk tartozo
adatteruletek (ez utobbi adatteruletekre pelda egy-egy diszk-blokk tartalma). A bu er
fejlecek egy-egy bu errel kapcsolatban a kovetkez} informaciokat tartalmazzak:
o
Annak az eszkoznek az azonos tojat (major/minor device sorszam), amelyr}l a
o
bu erhez tartozo adatteruleten tarolt memoriaterulet tartalmat betoltottuk.
A bu erben tarolt adatterulet c met (pl. szektor-sorszamat) azon az eszkozon belul,
amelyr}l a bu er tartalmat beolvastuk.
o
Egy mutato egy adatteruletre, ahol az eszkozr}l beolvasott blokk/szektor tartalma
o
van, illetve tarolva van, az adatterulet merete, es az, hogy hogy az adott adatteruleten mennyi az "ertekes" adat.
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A bu er allapotat le ro jelz}ket (ld. kes}bb).
o
o
A bu er fejlecek tobb kulonboz} listaba is fel vannak f}zve kulonfele celokkal. A
o
u
kovetkez}kben felsorolom azt, hogy milyen listak vannak, amelyre a bu er fejlecek fel
o
lehetnek f}zve:
u

Foglalt bu erek : ezen a listan azok a bu erek vannak, amelyeknek a tartalmanak
a zikai memoriaban kell lennie (ilyen peldaul egy fajlrendszer szuperblokkja).
Cache bu erek : ezen a listan azok a bu erek vannak, amelyeknek a
tartalmat eppen senki sem hasznalja (azert kerultek be, mivel tartalmukat
valaki kicsit korabban hasznalta) ha nem lesz mas szabad bu er, akkor ezek
"ujrafelhasznalhatok" lesznek helysz}ke eseten.
u

Elevult bu erek sora : ezen a listan azok a bu erek lesznek, amelyekre a
kes}bbiekben nagy valosz n}seggel nem fognak hivatkozni. Ha szukseg lenne uj
o
u
bu erek beolvasasara, es nincs mas szabad bu er-fejlec, akkor innen el lehet venni
barmelyik bu ert.
Ures bu er fejlecek sora : csak bu er fejlecek vannak, amelyek nem tarolnak
adatot (nincsenek hasznalva).

Egy eszkozmeghajtonak atadott bu erek sora : minden blokk eleres}
u

eszkoznek van egy sora, amelyen azok a bu erek (illetve fejleceik) vannak, amelyeken az adott eszkozmeghajtonak valamit el kell vegeznie (pl. a bu er tartalmat
vissza kell rnia a diszkre, ...).
A kovetkez}kben le rom a bu er cache rendszer interfeszet alkoto eljarasokat:
o
Egy eszkoz azonos tojat es annak egy blokkjanak a c met megadva megh vhatjuk
a getblk() vagy a bread() m}veleteket, amely visszaad egy bu er fejlecet az
u
adott eszkoz adott blokkjahoz. A visszaadott bu er a getblk() h vasa utan nem
feltetlenul tartalmazza a megadott eszkoz-blokk tartalmat (csak akkor tartalmazza,
o
o
ha a B DONE jelz} a bu er allapotjelz}i kozott be van all tva). Ha a bread()
m}veletet h vjuk meg, akkor a megadott eszkozr}l a megadott blokk tartalma
u
o
be lesz olvasva, es a bu erhez kapcsolt adatteruletre lesz rva. Mindket eljaras
megh vasa utan a bu er "hasznalat alatt lev}nek" lesz nyilvan tva: addig, am g ez
o
a jelz} ki nem lesz kapcsolva, mas nem vegezhet rajta semmit. Megjegyezzuk, hogy
o
a getblk() m}veletet olyankor szoktak megh vni, ha a diszk-blokk illetve a bu er
u
tartalmat teljesen at akarjak rni, gy nincs szukseg az el}z} tartalmara.
oo
A breada() m}velet hasonl t a bread()-hez, de van meg egy argumentuma, amelyu
ben megadhatjuk, hogy meg hany blokknyit olvasson el}re a megadott egysegen (de
o
a tovabbi blokkok aszinkron lesznek beolvasva, vagyis az eljarast vegrehajto folyamat futasa csak az explicite megadott blokk beolvasasaig lesz felfuggesztve).
A brelse() m}veletnek meg kell adni egy bu er fejlecenek a c met, es ezutan a
u
bu er rakerul a szabad bu ereket tartalmazo listakra.
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A bwrite() m}velet a bu ert annak az eszkozmeghajtonak a bu er-sorara rakja,
u
amelyr}l a bu er tartalmat beolvastuk, es a bu ert visszairatja az eszkozre oda,
o
ahonnan beolvastuk. Var, am g a bu er nem lett vissza rva. Ezt akkor szokas
megh vni, ha pontosan tudni akarjuk, hogy sikerult-e a vissza ras, es k vancsiak
vagyunk a vissza ras esetleges sikertelensegenek az okara.
A bawrite() m}velet a bwrite()-hoz hasonloan m}kodik, de nem var a bu er
u
u
vissza rasaig. Ez biztos tja a maximalis parhuzamossagot, mivel a vissza ras a
folyamat tovabbi futasaval parhuzamosan tortenhet.
A bdwrite() m}velet nem kezdemenyez I/O m}veletet a bu er tartalmanak a visu
u
sza rasara, de a bu ert rarakja a szabad bu erek listajara, es "modos tott"-nak
jelzi. Ez azt jelenti, hogy miel}tt valaki ujrafelhasznalna (leszedne a szabad bu ero
eket tarolo listarol), a bu er tartalmat vissza kell rni oda, ahonnan beolvastuk.
Ezt az eljarast akkor hasznaljak, ha nem biztosak abban, hogy a bu ert mar vissza
kell rni (mivel peldaul az utolso ra vonatkozo write() rendszerh vas nem toltotte
fel teljesen, gy varhato, hogy modos tani fogjak).
Mar eml tettem, hogy minden bu er fejlece tartalmaz egy jelz}t, amely a bu er
o
allapotat rja le. E jelz} erteket a kovetkez} biteknek megfelel} allapotjellemz}k logikai
o
o
o
o
"VAGY" kapcsolataval jellemezhetjuk:
B READ : ez azt jelzi, hogy a bu ert az eszkozmeghajtonak atadtuk, hogy olvassa
be a tartalmat a diszkr}l.
o
B WRITE : ez azt jelzi, hogy a bu ert az eszkozmeghajtonak atadtuk, hogy rja ki a
tartalmat a diszkre. Megjegyezzuk, hogy a B WRITE konstans erteke nulla, vagyis az
eszkozmeghajto ha nem talalja a B READ jelz}t beall tva, akkor B WRITE-ot feltetelez.
o
B DONE : ez a jelz} ki lesz kapcsolva miel}tt a bu ert atadjuk az eszkozmeghajtonak
o
o
valamilyen m}velet elvegzesere, majd miutan az eszkozmeghajto elvegezte a kijelolt
u
m}veletet, beall tja ezt a bitet.
u
B ERROR : a B DONE jelz}vel kozosen jelezhetik, hogy a bu eren kert I/O m}veletet
o
u
az eszkozmeghajto befejezte, de a m}veletet nem lehetett sikeresen vegrehajtani.
u
B BUSY : azt jelzi, hogy a bu ert valaki hasznalja. Am g ez a jelz} be van all tva,
o
addig mas nem hasznalhatja a bu ert. Ha getblk() vagy bread() m}velettel
u
akarunk beolvasni egy hasznalatban lev} bu ert, akkor ezek addig varnak, am g
o
ezt a jelz}bitet ki nem kapcsolja a bu er aktualis hasznaloja (a sleep()/wakeup()
o
mechanizmussal var), majd beall tja ezt a bitet, es visszaadja a bu ert a ker}nek.
o
B ASYNC : ez a jelz} akkor lesz beall tva, ha a bu ert a bawrite() m}velettel rtak
o
u
vissza. Ha ez a jelz} be van all tva, akkor a bu erre vonatkozo I/O m}velet befeo
u
jezese utan a bu erre vonatkozoan automatikusan vegre kell hajtani a brelse()
m}veletet.
u
B DELWRIT : ez a jelz} akkor lesz beall va, ha a bu ert a bdwrite() m}velettel rtak
o
u
vissza. Ha a getblk() egy adott bu er keresesekor a bu ert megtalalta, es ez a bit
be van all tva, akkor a bu er tartalmat atadja az eszkozmeghajtonak vissza rasra
miel}tt visszaterne a h vohoz.
o
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7.5 A fajlrendszer implementacioja
A UNIX-szer} operacios rendszerek rendszermagjai ( gy a BSD, a System V es a Linux is)
u
a fajlrendszereket csak blokk-eleres} eszkozokon, a bu er cache-nek a fajlrendszerkezel}
u
o
es az eszkozmeghajto koze helyezve tudjak letrehozni es kezelni { peldaul egy oppyn,
winchesteren, CD-ROM egysegen . A tovabbiakban a fajlrendszert tartalmazo eszkozt
diszknek nevezzuk, de ez alatt barmilyen blokk-eleres} eszkozt is erthetunk. Ebben a
u
pontban el}szor attekintjuk a fajlrendszer implementaciojaval kapcsolatos diszken tarolt
o
adatszerkezeteket, majd attekintjuk az ezeket modos to mechanizmusokat.
:::

A fajlrendszer szerkezete es implementacioja sokfele lehet az eredeti UNIX Version 7
fajlrendszer meg viszonylag sok korlatozast tartalmaz (peldaul max. 14 karakter hosszu
fajlnevek, nincsenek szimbolikus linkek). Lenyegeben ugyanezt a fajlrendszert tartalmazza a UNIX System V Release 3, es egy ugyanilyen szemantikaju fajlrendszert implementaltak a MINIX operacios rendszerben, amit atvettek a Linux operacios rendszerben is, es mint a Linux els} (es egyben legprimit vebb) fajlrendszeret nagyon sokaig
o
hasznaltak (kezdetben nem lehetett Linuxot futtatni MINIX operacios rendszer licensz
nelkul, mivel a Linuxnak akkoriban nem volt fajlrendszer-letrehozo segedprogramja).
Erdemes megjegyezni, hogy a MINIX fajlrendszere a diszken tarolt formatumaban
lenyegesen kulonbozott a UNIX Version 7 fajlrendszeret}l (m g a szabad blokkok ilo
letve i-node-ok a Version 7 UNIX-ben lista adatszerkezetben voltak nyilvantartva,
addig a MINIX bitterkepeket vezetett be ezeknek az informacioknak a tarolasara,
ami lenyegesen gyorsabbnak bizonyult a korabbi megoldasoknal). A 4.2BSD illetve
4.3BSD operacios rendszerek fajlrendszerenek felep tese lenyeges uj tasokat tartalmazott,
leginkabb a jobb hatekonysag elerese, valamint a korabbi fajlrendszer implementaciok
zavaro korlatozasainak a kikuszobolese erdekeben. Ez utobbi kategoriaba es} valtozasok
o
kozul talan a szimbolikus linkek megjelenese, valamint a maximum 255 karakter hosszu
fajlnevek megjelenese a legfontosabb. A jobb hatekonysagot pedig tobbek kozt a diszk roolvaso fejenek a mozgasanak a minimalizalasaval, valamint a diszk hardver adottsagainak
(pl. interleaving) a kihasznalasaval ertek el. A 4.2BSD ill. 4.3BSD uj, un FFS (Fast File
System { magyarul: gyors (eleres}) fajlrendszer) fajlrendszerenek alapjan terveztek meg
u
a Linux operacios rendszer ext2 fajlrendszeret a hasonlo hatekonysag es szolgaltatasok
biztos tasa erdekeben.
A modern rendszermag implementaciok tobbfele fajlrendszert pust is tudnak egyszerre kezelni { altalaban egy un. virtualis fajlrendszer retegnek a fajlrendszer kezel}
o
es a bu er cache koze torten} beillesztesevel: amikor egy fajlt hasznalni/modos tani
o
akarnak, akkor a virtualis fajlrendszer reteg megvizsgalja, hogy az adott fajl milyen
felep tes} fajlrendszeren van (ekkor egy fajl szerkezetet le ro adatstrukturaban (amit
u
majd kes}bb meg latni fogunk) a fajlt tartalmazo fajlrendszer t pusat is tarolni kell),
o
es a megfelel} fajlrendszer fajlkezel} m}veletet implementalo eljarast h vja meg a feladat
o
o u
elvegesere. A tovabbiakban egy igen elterjedt fajlrendszert fogunk megismerni: a 4.2BSD
FFS fajlrendszeret { ez talan a legbonyolultabb es a leghatekonyabb az eddig elkeszult
fajlrendszer implementaciok kozul, de szerkezetukben es funkciojukban az osszes tobbi
eddig elkeszult fajlrendszer hasonl t ra, gy a tobbi fajlrendszerr}l is egy atfogo es pontos
o
kepet alkothatunk a FFS megismerese utan.
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7.5.1 A diszken tarolt adatszerkezetek

Egy fajlrendszer egy magneslemezegysegen vagy annak egy particiojan helyezkedhet el
{ e ket eset kozott a kulonbseg csak annyi, hogy a teljes diszk kezeles szempontjabol
tekinthet} egy olyan part cionak, amely a teljes diszket lefedi, m g egy part cio tekinthet}
o
o
egy olyan "kisebb diszknek", amelyen a szektorok szamozasa nem nullanal kezd}dik, es
o
a merete is kisebb, mint a teljes diszk merete. A tovabbiakban nem teszunk kulonbseget
e ket eset kozott az el}bbi meggondolasok miatt, es a fajlrendszert tartalmazo diszket
o
vagy diszk-part ciot ezutan logikai diszknek fogom nevezni.
A logikai diszk els} szektora az un. boot-szektor, ami tartalmazza az un. els}dleges
o
o
operacios rendszer betolt} programot. Az els}dleges operacios rendszer betolt} programo
o
o
nak a merete nagyon kicsi, ezert altalaban csak annyit tud tenni, hogy betolti az utana
lev} szektorokrol (el}re le xalt elhelyezkedes}) masodlagos operacios rendszer betolt}
o
o
u
o
programot. A masodlagos operacios rendszer betolt} program pedig mar ismeri a logikai
o
diszken tarolt fajlrendszer formatumat, es onnan tolti be a gyakran tobb megabyte meret}
u
operacios rendszert (amelynek a fajlrendszerben egy jol meghatarozott helyen kell lennie
(a System V rendszereknel gyakran a /unix a neve, a BSD rendszereknel pedig /vmunix a
neve a Linux rendszerben pedig a leggyakoribb a /vmlinux vagy /vmlinuz fajlnev), de ez
a "jol meghatarozott" hely kovetelmeny mar csak egy fajlnevet rogz t, ahol az operacios
rendszer magja megtalalhato, nem pedig x diszk-szektor sorszamokat feltetelez).
A logikai diszknek az els}dleges illetve masodlagos operacios rendszer betolt} proo
o
gramjat tartalmazo szektorokat kovet} resze un. cilinder-csoportokra van felosztva
o
(a Linux operacios rendszer ext2 fajlrendszerenel hasonlo a helyzet, de ott ezeket az
egysegeket blokk-csoportoknak nevezik): a zikai diszk egymast kovet} valahany un.
o
cilindere (koncentrikus kor alaku hengerei) alkot egy cilinder-csoportot, es ezt az absztrakciot olyan meggondolasbol hoztak letre, es ugy alak tottak ki, hogy egy cilindercsoporton belul a zikai lemez olvasofejenek minimalis mozgast kelljen vegeznie. A gyakorlatban egy cilinder-csoport merete 8 megabajt korul van (de ennel lehet tobb is vagy akar
kevesebb is). Minden cilinder-csoport szerkezete hasonlo: van benne egy szuperblokk,
egy cilindercsoport-blokk, egy i-node tabla valamint adatokat (fajlokat es directorykat)
tartalmazo szektorok.
A szuperblokk tartalmazza a fajlrendszer meretere es szerkezetere vonatkozo informaciokat:
A fajlrendszer merete blokkokban
Egy blokk merete bajtokban
A blokknal kisebb teruletfoglalasi egyseg meretet (fragment3-meretet)
A fajlrendszerben maximalisan allokalhato i-node-ok szama, valamint a meg szabad
i-node-ok szama (ezekr}l az objektumokrol korabban mar rtam, de meg szo lesz
o
roluk reszletesebben).
3 Mivel a fajlrendszer blokk-merete gyakran 4 vagy 8K, es a fajlok nagy resze ezeknel joval kisebb (egyes
jelentese szerint egy "tipikus" rendszerben az atlagos felhasznaloi fahl merete kb. 1.5K), ezert ha egy 1.5K
meret} fajlnak lefoglalunk egy 8K meret} blokkot, akkor a blokk kihasznalatlan resze (ebben a peldaban
u
u
ez 6.5K) elveszne, ezert a FFS fajlrendszer tervez}i bevezettek a blokknal kisebb allokacios egyseget, az un.
o
fragmentet. Megjegyezzuk, hogy egy fajlnak csak az utolso blokkja helyett lehet toredekblokkokat, fragmenteket
allokalni.
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A meg nem foglalt (szabad) fajlrendszerblokkok listajanak els} nehany elemet (az uj
o
BSD FFS fajlrendszerben ez atkerult a cilindercsoportonkent kezelt cilindercsoportblokkba, amit hamarosan reszletesebben megismerunk).
Az i-node-ok szamat egy cilinder-csoporton belul.

Lathattuk, hogy minden cilinder-csoport tartalmaz az elejen egy szuperblokkot: mivel
a szuperblokk olyan fontossagu, hogy nelkule az egesz fajlrendszerrel semmit sem lehetne
kezdeni (ui. nem lehetne pontosan tudni olyan adatokat, mint peldaul a cilindercsoportok merete), ezert az osszes cilinder-csoport a szuperblokk egy-egy masolatat tartalmazza, es az osszes szuperblokk-peldanyban ugyanazok az adatok talalhatoak meg
(vagyis ha az egyik szuperblokk megserulne, akkor egy masik szuperblokkot hasznalva a
fajlrendszer tartalma meg megmenthet}).
o
Egy cilinder-csoportban a szuperblokkot a cilindercsoport-blokk koveti, amelynek
a feladata a cilinder-csoportra lokalis jellemz}k le rasa. Ez a kovetkez} lenyeges ino
o
formaciokat tartalmazza:
A cilinder-csoporton belul az adatblokkok szama.
A cilinder-csoporton belul az i-node-ok szama.
A cilinder-csoportban a szabad blokkok szama es elhelyezkedese.
A cilinder-csoportban a szabad fragmentek szama es elhelyezkedese.
A cilinder-csoportban a szabad inode-ok szama es elhelyezkedese.
Minden cilinder-csoport tartalmazza a cilinder-csoportot le ro blokk utan a cilindercsoport i-node tablajat. Mar eml tettem, hogy az i-node a fajlrendszer objektumainak
(fajlok, directoryk) az attributumait, a fajlrendszerbeli elhelyezkedeset es egyeb jellemz}it
o
tartalmazo objektum. Egy i-node tehat a kovetkez} fajl-attributumokat es egyeb
o
jellemz}ket tarol egy fajlrol:
o
A fajlra mutato linkek szama (a szimbolikus linkek nelkul!).
A fajl rwx-bitjei.
A fajl t pusa (regularis fajl, directory, blokk-specialis, karakter-specialis, szimbolikus link, vagy mas)
A tulajdonos felhasznaloi es csoportazonos toja.
A fajl hossza.
A fajl utolso modos tasanak a datuma.
A fajl utolso eleresenek a datuma.
A fajl i-node-janak az utolso modos tasanak a datuma.
A fajl elhelyezkedeset le ro "terkep" (ennek a terkepnek a szerkezeter}l mar rtam
o
a 2.4. pontban).
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A cilinder-csoport i-node tabla utani blokkjai a fajlrendszerben tarolt fajlok blokkjait,
valamint a fajlok elhelyezkedesenek a felterkepezeset le ro indirekt blokkok (ld. 2.4.
pontban) tartalmat tartalmazza.
Korabban mar azt is lathattuk, hogy a directoryk (konyvtarak) is fajlok, de a fajlt pusukkent nem a regularis fajl van nyilvantartva, hanem a directory fajl, es azt is lattuk,
hogy a tartalma is rogz tett formatumu. A korabban mar bemutatott (System V ill.
MINIX) directory formatuma csak a legfeljebb 14-karakteres fajlnevek hasznalatat tette
lehet}ve, es egy directory-bejegyzes (a directoryben lev} egy-egy fajlrol nyilvantartott
o
o
adat) 16 bajt, x hosszusagu volt. A 4.3BSD FFS fajlrendszereben egy fajl neve maximum
255 karakter hosszu lehet, es a directoryk szerkezete ugy modosult, hogy egy directorybejegyzes (ami egy fajlnevet tartalmaz, es egy directory pedig ilyen directory-bejegyzesek
sorozatabol all) valtozo hosszusagu lehet, es a directoryn belul kialak tottak egy teljes
szabad-lista kezelest, amely listara az egyes directory-bejegyzesek egymas utan fel vannak f}zve, es ha egy uj fajlt hozunk letre egy directoryban, akkor a rendszermag el}szor
u
o
megnezi, hogy valamelyik directory-bejegyzesben van-e annyi hely, hogy azt ket bejegyzesse osztva elfer-e az uj fajl neve es i-node-sorszama a szukseges lista-adminisztracios
adatokkal vagy sem. Ha van eleg hely, akkor az uj fajl felvitele gy megoldhato ha nincs
eleg hely, akkor a directoryt tartalmazo specialis fajl reszere ujabb blokk lesz lefoglalva,
es ott egy uj listaelemkent ujabb directory-bejegyzes lesz allokalva.
Korabban mar lattuk a linkek tarolasmodjat es nyilvantartasat a directorybejegyzesekben. A BSD FFS fajlrendszerben bevezetett szimbolikus linkek tarolasa attol
lenyegesen elter: a szimbolikus linkek egy specialis szimbolikus link t pusu fajlban vannak
tarolva a fajl tartalma ilyenkor maga a szimbolikus link altal mutatott fajlrendszerbeli
objektumnak a neve (vagyis ott nem i-node sorszam van tarolva). Ezzel lehet}ve valt
o
az, hogy egy szimbolikus link egy masik fajlrendszerben (pl. masik diszken tarolt) fajlra
is mutathasson, nincsenek olyan korlatozasok, mint a korabban bemutatott (un. hard
link t pusu) linkeknel, hogy csak egy fajlrendszeren belul lehet linkeket letrehozni, de
fajlrendszerek kozott "atmutato" linkeket nem lehet letrehozni. Termeszetesen ennek
megvan az a hatranya, hogy el}fordulhatnak olyan szimbolikus linkek, amelyek a "semo
mibe" mutatnak, mert peldaul letoroltek azt a fajlt, ahova a szimbolikus link mutat.
A szimbolikus linkek konzisztenciajanak az elfogadhato id}n beluli ellen}rzesenek nincs
o
o
kialakult modszere, nem is foglalkoznak vele.
A diszk-blokkok illetve az i-node tabla elemeit alkoto i-node-ok foglaltsagat altalaban
egy bitterkeppel kezelik: az adatterulet elejen lefoglalnak annyi blokkot, amely legalabb
annyi bitet tartalmaz, ahany diszk-blokk (illetve i-node) van az adott cilider-csoporton
belul. Ezen az adatteruleten minden egyes objektumrol (diszk-blokknak vagy i-nodenak)
tarolva van az, hogy szabad-e vagy pedig ertekes informaciot tartalmaz (azaz foglalt).
Egy 0-as bit jelzi azt, ha szabad egy 1-es bit jelzi a foglaltsagot. A UNIX System
V Release 3.2 valtozataban illetve korabban meg nem vettek at a BSD UNIX FFS
fajlrendszeret es a szabad blokkokat egy listaban taroltak, ami lassabb megoldasnak bizonyult (a Linux ext2 fajlrendszerenek az el}dje, az ext fajlrendszerben is ezt a szabadlista
o
kezelesi modszert valasztottak (annak ellenere, hogy a MINIX fajlrendszerben, amib}l
o
kiindultak, nem ezt hasznaltak), de miutan lattak a hatekonysag romlasat, visszatertek
a bitterkepes modszerre).
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7.5.2 Az adatszerkezeteken operalo m}veletek
u

Az el}z} pontban attekintettuk a fajlrendszer szerkezetet a diszken. Ott lathattuk a
oo
fontosabb adatszerkezeteket, amiknek a kezelese es konzisztenciajanak biztos tasa a rendszermag fajlrendszer-kezel}jenek a feladata. Ebben a pontban attekintjuk azt, hogy
o
a rendszermag hogyan kezeli a fajlrendszereket, illetve milyen segedm}veletek megu
valos tasat tartalmazza.
A szuperblokk kezeleset altalaban a bu er cache szintjen, a bu er cache eljarasaival
vegzik: a fajlrendszereket a fajl-hierarchiaba illeszt} mount() rendszerh vaskor lesz a
o
szuperblokk beolvasva, es egeszen a megfelel} umount() rendszerh vasig bennmarad
o
a memoriaba. A szuperblokkokat a beillesztett fajlrendszerekre vonatkozo egyeb informaciokkal egyutt (peldaul azzal az informacioval egyutt, hogy melyik directorynal
van beillesztve a fajlrendszer tartalma) egy un. mount tablaban taroljak.
A hasznalt (azaz valamelyik rendszermag-komponens altal hivatkozott) i-node-ok
tarolasara is van egy tabla, az un. i-node tabla. Az i-node tabla egyreszt tarolja a logikai
diszken lev} fajlrendszerr}l behozott i-node tartalmat (statikus jellemz}ket), valamint az
o
o
o
i-node dinamikus jellemz}it: azokat a jellemz}ket, amiket csak egy "hasznalatban lev}"
o
o
o
i-node eseten kell nyilvantartani. Az i-node dinamikus jellemz}it a kovetkez} adatok
o
o
alkotjak:
Melyik eszkozr}l lett beolvasva.
o
Mi az adott i-node sorszama az eszkozon tarolt i-node-ok kozott.
Az i-node-ra van-e egy masik fajlrendszer illesztve (ld. mount tabla).
Ha az i-node-ra egy masik fajlrendszer ra van illesztve, akkor tarolni kell annak a
fajlrendszernek a mount-tabla beli azonos tojat (altalaban az i-node sorszamat).
Hany megnyitott fajl hivatkozik erre az i-node-ra.
Nyilvanvalo, hogy kell egy m}velet egy i-node-nak az i-node tablaba toltesere, es egy
u
modos tott i-node tartalmanak a logikai diszken lev} fajlrendszerre vissza rasara. Ezeket
o
altalaban ugy oldjak meg, hogy a megadott logikai diszkr}l beolvassak azt a blokkot,
o
amely az i-node-ot tartalmazza, modos tjak a bu erben a tartalmat, majd a bu ert
szinkron modon vissza rjak a diszkre (vagyis varnak, am g vissza nem lesz rva). Am g
a bu er tartalmat manipulaljak, addig a bu er hasznalatara kizarolagos jogot formal es
kap a rendszer megfelel} resze.
o
Fontos latni, hogy ha egy i-node mar benn van az i-node tablaban, akkor nem szabad
megegyszer betolteni, hanem a ra vonatkozo hivatkozasok szamat kell eggyel novelni, es
az i-node tablabeli el}z} peldanyat kell masoknak is hasznalni (ui. a POSIX es mas szoo
abvanyok a fajlrendszer szemantikajat ugy de nialjak, hogy ha egy folyamat valamilyen
valtoztatast vegez egy fajlon (ezzel a fajlt le ro i-node-on), akkor a valtoztatas utan mindenki ugyanazt a modos tott fajlt latja, es ez a kovetelmeny gy { az i-node ujraolvasasa
nelkul { konnyen biztos thato persze erre leteznek mas (bonyolultabb) megoldasok, de
tudtommal senki sem hasznalta }ket).
o
Szukseg van egy uj (addig szabad) i-node-ot allokalo m}veletre, illetve egy i-node
u
deallokalo m}veletre. Ezeknek a m}veleteknek az eredmenyekeppen nemcsak az i-node
u
u
tablaban tortenik valtozas, hanem a logikai diszken (az azt tartalmazo adathordozon)
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is a megfelel} cilinder-csoport blokkokat aktualizalni kell (ez nyilvan a megfelel} blokk
o
o
beolvasasaval illetve vissza rasaval jar, de a jelenlegi implementaciokezeknek nem szoktak
egy kulon tablat letrehozni es kezelni). A MINIX fajlrendszerben mivel a bitterkepek a
szuperblokkal egyutt voltak tarolva, ezert az i-node allokalo es deallokalo m}veletek a
u
szuperblokk objektum m}veletei voltak.
u
A cilinder-csoport i-node tabla utani reszet, az adatblokkok teruletenek a kezeleset
vegz} eljarasokat is meg kell rni: kell egy adatblokk-lefoglalo es egy adatblokk felo
szabad to eljaras. Ezeknek az eljarasoknak a megfelel} cilinder-csoport blokkot (az
o
adatblokk-foglaltsagi tablaval) modos taniuk kell az elvegzett m}velet alapjan.
u

7.5.3 Allokacios strategiak

Az el}bbiekben attekintettuk az FFS fajlrendszer f}bb adatszerkezeteit. Ezen ismeretek
o
o
birtokaban mar mindent meg tudunk csinalni egy fajlrendszerrel, de ahhoz, hogy ezeket
a MINIX (vagy System V Release 3.2) rendszermagjanak fajlrendszerehez kepest elegge
elbonyol tott adatszerkezeteket optimalisan ki lehessen hasznalni, kialak tottak egy-egy
blokk- illetve i-node-lefoglalasi strategiakat. Ezeket ismertetem ebben a pontban.
Az optimalizalasok altalaban a diszk olvasofejenek a mozgas-palyajat probaljak meg
minimalissa tenni bizonyos tipikus m}velet-sorozatok alkalmaval.
u
Peldaul egy adott directory tartalmat listazo ls parancs a directoryban lev} osszes
o
fajlt es directoryt (azok i-nodejat) eler annak erdekeben, hogy azokrol informaciokat
gy}jtson be (pl. egy fajl hosszat ki tudja rni, ...). Ezert az egy directoryban lev}
u
o
fajlok i-nodejaik a szul}directoryval egyutt ugyanabban a cilinder-csoportban vannak.
o
Mivel nem lehet az osszes fajl es directory ugyanabban a cilinder-csoportban, az is egy
konvencio, hogy a directoryk i-nodejaikat az szul} directory i-nodejat tartalmazo cilindero
csoportba nem rakjak, hanem az mindig egy masik cilinder-csoportba kerul (a megfelel}
o
cilinder-csoportot ugy valasztjak ki, hogy megnezik, hogy melyik cilinder-csoportban
van a legtobb szabad (nem hasznalt) i-node, es ebben a cilinder-csoportban hoznak letre
egy uj directoryt). Termeszetesen ha valamelyik cilinder-csoportban nincs szabad (nem
hasznalt) i-node, akkor egy masik cilinder-csoportot kell valasztani.
Az adatblokkok elhelyezesere is vannak szabalyok, meghozza itt inkabb arra
torekednek, hogy egy fajl adatblokkjai abbad a cilinder-csoportban helyezkedjenek el,
amelyben a fajl i-node-ja van. Mivel nagy fajlok eseten egy fajl osszes adatblokkja nem
kerulhet ugyanabba a cilinder-csoportba, ezert az is egy szabaly, hogy egy fajl minden
egyes x nagysagu reszet (pl. megabajtjat) megprobaljak mas-mas cilinder-csoportokba
elhelyezni, de ha nem sikerul, akkor persze feladjak az optimalizacios torekveseket, es
keresnek megfelel} nagysagu szabad helyet, es ott helyezik el az adatokat.
o

7.5.4 Fajlnevr}l - i-nodera transzformacio
o

A fajlkezel} rendszer egyik gyakori feladata a fajl abszolut vagy relativ eleresi neve alapjan
o
a fajlhoz tartozo i-node megkeresese. Ennek az algoritmusnak tehat az inputja egy fajlnev
(abszolut vagy relativ), outputja pedig egy i-node hivatkozas illetve egy logikai ertek, ami
azt jelzi, hogy sikeres volt-e a transzformacio.
A transzformacio els} lepesekent meg lesz hatarozva egy kezd} directory: abszolut
o
o
fajlnevek eseten (ha a fajl eleresi nevenek els} karaktere egy "/" jel) a gyoker-directory
o
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relativ fajlnevek eseten (vagyis ha a fajl eleresi nevenek az els} karaktere nem egy "/"
o
jel) pedig a folyamat munkadirectoryja.
A rendszermag ellen}rzi, hogy ez valoban egy directory-e, es valoban van-e ra keresesi
o
engedelyunk. Ha nem directory vagy nincs jogunk benne keresesre, akkor egy hibakoddal
visszater.
Ezutan le lesz valasztva a fajl eleresi nevenek a kovetkez} komponense (a kovetkez}
o
o
"/" karakterig tart), es a rendszermag megkeresi az ilyen nev} bejegyzest a kezd} directou
o
ryban, es hibakoddal ter vissza, ha nem talalja ha pedig megtalalja, akkor a directoryban
a hozza tartozo i-node sorszama alapjan be lesz toltve az i-node, es ezt az uj i-node-ot
mint kezd} directoryt felhasznalva ugyanezt ismetli, am g sikeres a transzformacio ("elfo
ogyott a fajl eleresi neve") vagy sikertelen a transzformacio. A sikertelenseget tobb
tenyez} is okozhatja: vagy nincs olyan directory, amire a fajl eleresi neveben hivatkoztak
o
(az is lehet, hogy van olyan nev} directory bejegyzes, de az nem directoryra, hanem
u
egy fajl t pusu i-node-ra mutat), vagy nincs a directoryra keresesi jog. Termeszetesen
az is hiba, ha az inputkent megadott fajl eleresi nevben meg vannak komponensek, de
a directory-hierarchiaban mar nem tudunk "lejjebb" menni (mert a tovabbhaladashoz
szukseges komponens hianyzik).
Ha menet kozben olyan i-node-hoz ertunk, amelyre egy masik fajlrendszer van
beillesztve, akkor a beillesztett fajlrendszer mount tablaban lev} szuperblokkja alapjan
o
be lesz toltve a beillesztett fajlrendszer gyoker-directoryja, es a kereses ott folytatodik.
Visszafele ugyanez megvan: ha a ".." (szul} directory) bejegyzesre egy gyoker-directory
o
eseteben hivatkoznak, akkor megkeresik azt, hogy az a bizonyos hivatkozott gyoker directory melyik i-node-ra van raillesztve, es ennel az i-node-nal folytatodik a fajlnevr}l
o
i-node-ra transzformacio.
A hard linkek kezelese semmi problemat nem okoz az algoritmusunknak a szimbolikus
linkek feldolgozasa pedig csak annyi nehezseget okoz, hogy vigyazni kell, nehogy vegtelen
ciklusba keveredjen a transzformacios algoritmus valamilyen veletlenul vagy szandekosan
rosszul letrehozott szimbolikus link miatt. Ezt ugy oldjak meg, hogy korlatozzak az
egy fajlnev i-node-ra transzformalasa soran maximalisan el}fordulhato szimbolikus linkek
o
szamat.

7.5.5 A rendszerh vas interfesz

A fajlrendszerkezel} kod egy jol szeparalhato reszet alkotjak a rendszerh vasokat feldolo
gozo eljarasok. Ezek az eljarasok lesznek megh vva olyankor, amikor egy alkalmazas egy
rendszerh vast hajt vegre, es ezek h vjak meg az alacsonyszint} i-node es mas m}veleteket
u
u
a rendszerh vas feladatanak elvegzesehez.
Azok a rendszerh vasok, amelyek fajlokat megnyitnak illetve letrehoznak (altalaban
ezek az open() illetve a creat() rendszerh vasok), altalaban egy fajlnevet varnak az argumentumaikban, es egy { korabban mar eml tett { fajldeszkriptorral ternek vissza. Azok
a rendszerh vasok, amelyek egy mar megnyitott fajlon vegeznek valamilyen m}veletet,
u
a megnyitott fajl fajldeszkriptorat varjak altalaban els} argumentumukkent. Lattuk
o
mar, hogy ezek a fajldeszkriptorok egesz (C nyelven int) t pusuak, es ha peldaul kiirattuk az ertekuket, akkor lathattuk, hogy altalaban 0-tol kezd}d}en lesznek szamozva,
oo
es van egy maximalis ertekuk is (legfeljebb ennyi fajlt hozhat letre egy folyamat). Mar
eml tettem, hogy a folyamat user strukturaja tartalmazza azt a tablazatot, amely a
fajldeszkriptorokhoz a globalis fajl tabla egy elemet rendeli. Ebben a globalis tablaban az
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osszes megnyitott fajlrol nyilvantartanak bizonyos informaciokat (peldaul azt, hogy hany
folyamat hany fajldeszkriptora hivatkozik arra a tablaelemre), de itt van nyilvantartva az
is, hogy mi az aktualis fajl-poz cio a fajlon belul (es ha vegrehajtunk egy read(), write()
vagy egy lseek() rendszerh vast, akkor ez az ebben a tablaban tarolt fajl-poz cio alapjan
tudja, hogy hol tartunk a fajl feldolgozasaban illetve ezt a tablazatot megfelel}en aktuo
alizalni is fogja). Megjegyezzuk, hogy ha ketszer egymas utan open() rendszerh vassal
megnyitunk egy fajlt, akkor a globalis fajl tablaban ket tablaelem fog letrejonni ha viszont dup() rendszerh vassal egy fajlhoz letrehozunk egy uj fajldeszkriptort, akkor az eredeti fajldeszkriptorhoz tartozo globalis fajltabla-elemhez fog letrejonni egy uj hivatkozas
az uj fajldeszkriptoron keresztul.
Megjegyezzuk, hogy a socket rendszerben egy fajldeszkriptorhoz nem csak egy globalis
fajltablabeli elem tartozhat, hanem egy { hasonlo celu { globalis socket-tablabeli elem
is ezzel ebben a kiadasban nem foglalkozunk.

7.6 A kommunikacios alrendszer implementacioja
Ebben a fejezetben a rendszermag ket alapvet} folyamatok kozotti kommunikacios
o
eszkozet, a signal()-okat, valamint a pipe-okat fogjuk attekinteni.
Egy signal generalasakor4 a proc strukturaba bejegyzesre kerul az, hogy milyen
signalt kuldtek a folyamatnak. Ha egy folyamat akozben kap signalt, mikozben egy
rendszerh vast hajt vegre, akkor a signal-kezel} csak azutan lesz vegrehajtva, miutan a
o
rendszermagbeli futas befejez}dik (miel}tt a folyamat vegrehajtana a visszaterest a felo
o
hasznaloi programba, ellen}rzi, hogy kuldtek-e neki egy signalt) egyeb esetben a signalo
kezel} azonnal vegrehajthato.
o
A pipe() rendszerh vas egy cs}vonalat hoz letre, a hozza tartozo fajldeszkriptoro
tablabeli bejegyzesekkel egyutt. A pipe objektumok altalaban olyan fajlokkent vannak implementalva, amely fajlra vonatkozoan nincs hivatkozas a fajlrendszerben egy
directory-bejegyzesb}l sem. Termeszetesen tartozik hozza egy i-node (amit altalaban
o
a gyoker-directoryt is tartalmazo gyoker-fajlrendszerben allokalnak), amelynek a merete
gyakran korlatozva van (tipikus meretkorlatozas az, hogy a pipe-ok tartalmat kepez}
o
adatok tarolasara csak direkt blokkokat hasznalnak, nem hasznalnak egyszeres, ketszere
illetve haromszoros indirekt blokkokat). A pipe-ba rt adatokat a letrehozott i-node-hoz
tartozo adatteruleten tehat el lehet tarolni vagyis amikor adatokat runk egy pipe-ba,
akkor a rendszermag ellen}rzi, hogy a fel rando adatok befernek-e a pipe-ba, es ha igen,
o
akkor be rja (ezzel a pipe meretet megfelel}en modos tja) ha pedig nincs eleg hely, akkor
o
vagy be r valmennyi adatot a pipe-ba es a write() rendszerh vas visszaadja, hogy mennyit rtak a pipe-ba, vagy pedig visszater azzal, hogy blokkolna a pipe-ba ras. A globalis
fajltablaban ket elem van allokalva: az egyik az rasi oldalhoz, a masik pedig az olvasasi
oldalhoz. Amennyiben az i ro folyamatok tele rjak a pipe-ot, akkor az ujabb roknak
varniuk kell, am g az olvasok nem olvassak ki a pipe-ban lev} osszes adatot, majd a pipe
o
olvasasa illetve rasa ujrakezd}dhet { ugy, hogy mind az rasi, mind pedig az olvasasi
o
fajlpoz cio nullara lesz all tva.
4 Egy signalt vagy a kill() rendszerh vassal egy masik folyamat, vagy a rendszermag, vagy pedig a felhasznalo a ctrl-C billenty}k lenyomasaval generalhat.
u
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7.7 Kerdesek
Vajon miert nem lehet hard linkkel fajlrendszerek kozotti linket letrehozni?
Vajon a pipe-okhoz tartozo i-node-okat miert a gyoker-konyvtarat is tartalmazo
gyoker-fajlrendszerben szokas letrehozni?

Fejezet 8

A UNIX SYSTEM V STREAMS programozasa
Ebben a reszben a kommunikacios modulok implementalasanak az AT&T altal
kialak tott eszkozet: a STREAMS-et mutatjuk be. Megjegyzes: az ebben a fe-

jezetben le rt informaciok erdekesek, viszont egyreszt a tobbi fejezethez
kapcsolas, masreszt a le ras reszletessege (esetleg meg a pontossaga is)
k vannivalokat hagy maga utan. Ezt eredetileg egy kulon le raskent
kesz tettem (az el}z} fejezetek elkesz tese el}tt kb. 2 evvel), most csak a
oo
o
teljesseg kedveert raktam bele ebbe a le rasba.

8.1 Bevezetes
A STREAMS rendszert Dennis Ritchie kesz tette az ATT Bell Laboratoriumaban azzal a
cellal, hogy egy modularis I/O rendszer kiep tesere hasznalhato eszkozzel b}v tse a UNIX
o
rendszert. A STREAMS els} kommersz valtozata a UNIX System V Release 3 operacios
o
rendszerrel lett a fejleszt}k es a felhasznalok rendelkezesere bocsatva. Ma a STREAMS
o
rendszert hasznaljak sok helyen a UNIX terminalok vezerlesere, halozati protokollok
implementalasara es ez az alapja szamos mas felhasznaloi software rendszernek. Itt
eml tjuk meg, hogy a STREAMS seg tsegevel tudtak implementalni az ATT UNIX System V Release 4.0 rendszerben a 4.3BSD UNIX rendszerben hasznalt socketeket (a fenti
ket operacios rendszerben a sockets rendszer teljesen kompatibilis egymassal, gy a
Berkeley UNIX sockets rendszerh vasait hasznalo programokat konnyebben atvihetjuk az
ATT UNIX rendszerekre). A STREAMS mechanizmust csak az ATT UNIX tartalmazza,
a 4.3BSD UNIX-ban ez nincs implementalva. Ott is van lehet}seg hasonlo strukturak
o
felep tesere, de ott ez kisse nehezkesebben megy.

8.1.1 Alapfogalmak

A STREAMS egy UNIX kernelbe beep tett mechanizmus, mely lehet}ve tesz egy
o
ketiranyu kapcsolat kiep teset a felhasznaloi programok es a karakteres, adatkommunikacios STREAMS device driverek kozott. Eredetileg a UNIX terminalok vezerlesere
alak tottak ki, de kes}bb alkalmazhatonak bizonyult halozati protokollok impleo
mentalasara is. (A Release 4 UNIX mar STREAMS terminal-drivereket hasznal.) A
STREAMS device driverek adatokat kozvet thetnek a felhasznaloi programok es a hardware berendezesek kozott, de vannak specialis driverek is, peldaul a multiplexer driverek,
amelyek legtobbszor nem allnak a hardware periferiakkal kozvetlen kapcsolatban.
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Az adataramlas a driver es a felhasznaloi program kozott egyszerre ket iranyban folyhat: lefele a felhasznalotol a driverig (ezt nevezik write oldalnak) es felfele a drivert}l
o
a felhasznalo iranyaba (ezt nevezik read oldalnak is). Mindket iranyu adataramot
(streamet) egymas moge rakott sorok (queuek) seg tsegevel implementaljak. Egy stream
a STREAMS device drivert}l indul es a stream-fejben vegz}dik. A stream-fej tartja a
o
o
kapcsolatot a felhasznalo es a stream alsobb reszei kozott. Minden egyes STREAMS
driverre vonatkozo open rendszerh vas egy uj stream-fejet hoz letre (amennyiben a driver
ezt tamogatja).
A driver es a felhasznaloi program koze beilleszthetunk un. STREAMS modulokat, amik
se nem driverek, se nem stream-fejek (vagyis egy STREAMS modult nem szokas peldaul
open rendszerh vassal megnyitni). Feladatuk a rajtuk keresztulmen} adatok valamio
lyen modos tasa - peldaul protokollinformaciokkal kiegesz thetik azokat, vagy az egyes
modulok a nekik szolo informaciokat kivehetik a sorbol. Ha a STREAMS drivert megnyitjuk, akkor letrejon a stream-fej. A modulokat ezutan csak kozvetlenul a stream-fej
ala rakhatjuk az ioctl rendszerh vassal (a megfelel} parameterek beall tasaval).
o
A STREAMS driverek teljesen a kernel teruleten helyezkednek el, ezert ezek rasakor
kulonosen kell vigyazni, nehogy valami hibat csinaljunk!

8.1.2 A STREAMS el}nyei
o

A STREAMS seg tsegevel meg rt programok el}nyei: egyszer}bb szerkezet}ek (a feo
u
u
ladat szintenkenti megoldasat is tamogatja), konnyen alkalmazkodnak barmilyen konguraciohoz, es hordozhatoak. Felhasznalhato a hagyomanyos UNIX karakteres device
driverek helyett, es a folyamatok kozotti kommunikacio megoldasara is.
Egy streamet dinamikusan kon guralhatunk a futasid}ben, ezzel szemben egy
o
hagyomanyos UNIX device driver a futasid}ben mar kevesbe (vagy egyaltalan nem)
o
megvaltoztathato. (Lehet}seg van arra, hogy egy hagyomanyos UNIX karakteres device
o
drivert peldaul ioctl h vasokkal modos tsunk, de ez sokkal attekinthetetlenebb lenne,
mint az azonos feladat STREAMS megoldasa.)
Az egyes modulok kicserelhet}ek, gy ugyanazt a softwaret alkalmazhatjuk tobbfele kono
guracioban is. A STREAMS jo eszkozoket nyujt peldaul a halozati softwareek hardwarefugg} es hardwarefuggetlen reszenek elkulon tesehez - a fels}bb szinteket mar teljesen
o
o
hardwarefuggetlenul kodolhatjuk, hasznalhatjuk.

8.1.3 A STREAMS rendszer vezerlese
A STREAMS rendszert a ra vonatkozo
tot pusa a kovetkez} :
o

ioctl

h vasokkal vezerelhetjuk. Ennek pro-

int ioctl(int fd,int command,arg)

Itt fd egy nyitott STREAMS driverre vonatkozo ledeszkriptor. A command
parameter tartalmazza a vegrehajtando m}velet kodjat, es ett}l fugg az arg parameter
u
o
erteke. A rendszerh vas soran fellepett hibakat (ha az uzenetet nem tudta atadni a
stream-fej mogott lev} modulnak) a szokasos modon jelzi. (Lasd err}l reszletesebben a
o
o
STREAMIO le rast az egyes hibauzenetekr}l!) Az ioctl h vas utan az errno valtozo
o
erteke EINVAL lesz, es a h vas nem hajtodik vegre, ha az fd altal speci kalt stream mar
hozza van kapcsolva egy multiplexer driverhez (ld. kes}bb), vagy a command parameter
o
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tartalma nem egy jo STREAMS parancs-ertek.
A kovetkez}kben a leggyakrabban hasznalt STREAMS ioctl parancsok lesznek iso
mertetve :
I_PUSH : Bef}z egy modult kozvetlenul az fd altal megadott stream stream-feje
u
ala. Az arg parameter a bef}zend} modul nevere mutato karakter-pointer. Ezutan
u o
megh vodik a bef}zott modul open (megnyito) rutinja. Hiba eseten az errno
u
valtozo lehetseges ertekei :
{ EINVAL : A megadott modulnev nem ismert a kernelen belul.
{ EFAULT : Az arg a program c mtartomanyan k vulre mutat.
{ ENXIO : Open rutin hibat jelez, vagy hangup-ot kapott az fd-vel megadott
stream.
I_POP : Leszedi a megadott stream tetejen lev} modult. A h vasban arg erteke 0
o
kell legyen. Hiba eseten az errno valtozo lehetseges ertekei :
{ EINVAL : Nincs mar modul ennek a streamnek a stream-feje alatt.
{ ENXIO : Hangup-ot kapott az fd-vel megadott stream.
I_STR : Egy STREAMS M_IOCTL (ha szukseges, akkor utana meg egy M_DATA)
uzenetet general az alapjan, amire az arg parameter mutat, es elkuldi a lefele
men} streamen. A felhasznalo gy kuldhet ioctl h vasokat a moduloknak es a
o
drivereknek. A rendszer var addig, am g az uzenetet feldolgozo modul visszajelzest
ad arrol, hogy sikeres volt-e az ioctl h vas. Ha egy megadott id}n (default=15 sec.)
o
belul nem erkezik visszajelzes, akkor az ioctl h vas timeout hibaval megszakad.
Az arg parameter egy strioctl strukturara mutat. Ez tartalmazza a kovetkez}
o
mez}ket :
o
int ic_cmd
int ic_timout
int ic_len
char *ic_dp

/*
/*
/*
/*

Milyen ugyben kuldjuk ezt ? */
Mennyi ido mulva lesz timeout ? */
A lekuldendo adatterulet hossza */
Pointer az elkuldendo adatteruletre */

Az egyes mez}k jelentese a kovetkez} :
o
o
{ ic_cmd : A driver (vagy modul) ez alapjan tudja meg, hogy mit kell csinalnia.
{ ic_timout : Megadja, hogy maximum mennyi ideig kell varakozni a modul
(vagy driver) valaszara, vagyis mennyi id} mulva kovetkezzen be a timeout.
o
Ennek ertekei a kovetkez}k lehetnek :
o
-1 : vegtelen sokaig kell varni.
0 : a rendszerben defaultnak szam to ideig kell varni.
>0 : a parameterben megadott ideig kell varakozni a valaszra.
{ ic_len : Az ioctl h vas el}tt megadja, hogy milyen hosszu a streamen
o
lekuldend} ioctl-hez kapcsolodo adat hossza. Az ioctl h vas utan a driver
o
(ill. modul) altal felkuldott valasz hosszat tartalmazza (byteokban merve).
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{

: Arra az adatteruletre mutat, ahol a streamen lekuldend} informacio
o
van. A h vas befejez}desekor ide fogja a rendszer be rni az uzenetet feldolo
gozo modul altal visszakuldott valaszt, gy e terulet nagysaga legalabb akkora
legyen, mint a visszakuldhet} leghosszabb valasz nagysaga.
o
Ha az ioctl h vas sikertelen (ioctl visszaterese erteke : -1), akkor a hiba okat az
errno valtozo tartalmazza. Ennek lehetseges ertekei a kovetkez}k :
o
{ ENOSR : A stream-fej nem tud lefoglalni memoriateruletet az ioctl uzenetnek,
mert nincs eleg memoria.
{ EFAULT : Valamelyik pointer (arg vagy ic_dp) altal meghatarozott
memoriaterulet a process memoriatartomanyan k vul esik.
{ EINVAL : Vagy az ic_len altal megadott hossz nem esik az adott rendszeren
megengedett tartomanyba, vagy a ic_timout erteke -1-nel kisebb.
{ ENXIO : Hangup-ot kapott az fd-vel megadott stream.
{ ETIME : A stream-fej a ic_timout parameterben megadott id}n belul nem
o
kapott valaszt, a h vas timeout miatt befejez}dik.
o
ic_dp

8.1.4 A STREAMS uzenett pusai

Uzeneteknek nevezzuk a modulok lancan fel-le men} informaciokat, hibauzeneteket, stb.
o
Egy uzenet (message) egy vagy tobb uzenetblokkbol all. A STREAMS rendszerben egy
uzenetblokk es az adatblokkok felep teset a kovetkez} strukturak tartalmazzak :
o
struct msgb {
struct msgb *b_next
struct msgb *b_prev
struct msgb *b_cont
unsigned char *b_rptr
unsigned char *b_wptr
struct datab *b_datap
}

/*
/*
/*
/*
/*
/*

queue-n kovetkezo message */
elozo message a queuen */
tovabbi messageblokkok */
elso hasznos adatbyte*/
utolso hasznos byte utani adatbyte */
Adatblokkra pointer */

typedef struct msgb mblk_t
struct datab {
struct datab *db_freep
unsigned char *db_base
unsigned char *db_lim
unsigned char db_ref
unsigned char db_type
unsigned char db_class
}

/*
/*
/*
/*
/*
/*

Belso hasznalatra */
A buffer elso bytejara mutat */
A buffer utolso utani byteja */
Hany uzenet mutat erre az adatra */
Uzenettipus */
Belso hasznalatra */

typedef struct datab dblk_t

Megjegyzes: az egyes uzenetek nem biztos, hogy a teljes adatblokkot lefoglaljak. Azt, hogy egy uzenet
ertekes resze az adatblokkon belul hol kezd}dik az uzenetblokknak a b_rptr mez}jeb}l tudhato meg. Az
o
o o
uzenetblokk b_wptr mez}je pedig az adatblokk utolso ertekes byteja utani bytera mutat.
o
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A STREAMS megengedi az uzenetek osztalyozasat. A kulonfele uzenett pusokat felhasznalva vilagosabb szerkezet} programokat rhatunk. Ekkor a STREAMS szolgaltatast
u
vegz} rutin leggyakrabban csak egy uzenett pusok szerinti elagazast tartalmaz, es egy-egy
o
ag egy-egy uzenett pus feldolgozasaert felel}s. A STREAMS nagyon sokfele uzenett pust
o
ismer. Egy mblk_t *bp modon deklaralt uzenet t pusat a bp->b_datap->db_type kifejezes adja meg.
: A STREAMS modulok egymas kozti illetve driver es modulok kozti
protokollinformaciok tartoznak ebbe az uzenett pusba. A felhasznaloi programok
nem kuldhetnek lefele ilyen t pusu uzeneteket, mivel ezeket a stream-fej kisz}ri.
u
M_CTL

: Adatokat tartalmazo uzenetek. A felhasznalo ezeket a putmsg es
rendszerh vasokkal rhatja bele egy streambe, es a getmsg es read rendszerh vasokkal olvashatja ki a streamb}l.
o
M_DATA
write

: Ezzel az uzenettel kerheti valamelyik STREAMS modul a drivert}l az
o
output kesleltetett kiadasat (peldaul azert, mert nagyon lassu az output periferia).
Az uzenet formatuma nincs pontosabban meghatarozva, a programozo dontheti el,
hogy hogyan akarja felhasznalni. A felhasznaloi programok nem kuldhetnek lefele
ilyen uzeneteket, mivel ezeket a stream-fej kisz}ri.
u
M_DELAY

: A stream-fej a felhasznalo ioctl h vasait ilyen uzenet formajaban
tovabb tja az alatta lev} modulokhoz. Az ioctl-ben ekkor az I_STR parancsot kell
o
megadni. Az a modul, aki egy ilyen uzenetet feldolgozott, koteles ezt a stream-fej
iranyaba nyugtazni, mert a stream-fej addig nem tovabb t uzeneteket, am g nem
biztos benne, hogy az ioctl h vas hibatlanul lement.
M_IOCTL

: Protokoll-informaciokat a hozza tartozo adatokkal egyutt tartalmazo
uzenetek. A felhasznalo ezeket putmsg rendszerh vassal rhatja a streambe, es
getmsg rendszerh vassal olvashatja ki a streamb}l. Ezek az uzenetek nem kezelhet}k
o
o
read/write h vassal!.
M_PROTO

: Szinten protokoll-informaciokat tartalmaz, de magas a prioritasa.
A felhasznalo ezeket putmsg rendszerh vassal rhatja a streambe, es getmsg
rendszerh vassal olvashatja ki a streamb}l. Ezek az uzenetek nem kezelhet}k
o
o
read/write h vassal!. A normal (alacsony prioritasu) protokolladatoktol ezeket a
letrehozasukkor egy aggel kulonboztethetjuk meg a putmsg h vasban. A h vas
szintaxisa:
M_PCPROTO

putmsg(fd,ctlptr,dataptr,flags)
int fd
struct strbuf *ctlptr
struct strbuf *dataptr
int flags

Ha a flags parameter RS_HIPRI-re van all tva, akkor az uzenet magas prioritasu
uzenet lesz. (Egyebkent a flags parameter erteke : 0.) Lasd err}l reszletesebben
o
a UNIX Programmer's Reference Manualt.
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es
: Ezek az uzenetfajtak az ioctl h vasok nyugtazasara valok.
Az
uzenet egy hibakodot visz magaval a stream-fej iranyaba (csak hibakodot lehet gy a stream-fej iranyaba kuldeni, valaszadatokat nem). A M_IOCACK
valaszadatokat is kuldhet felfele (ez a pozit v visszajelzes).
M_IOCACK M_IOCNAK
M_IOCNAK

: Ezt az uzenetet a modulok vagy a driverek kuldhetik felfele a streamfej iranyaba, ha a lefele halado queuen valami hiba van. Ha ez az uzenet eleri a
stream-fejet, akkor az ezutan kiadott rendszerh vasok a close es a poll kivetelevel
hibaval fejez}dnek be, es a rendszer az uzenet els} bytejaban megadott hibakodot
o
o
adja vissza az errno valtozoban hibakodkent. A poll rendszerh vas a POLLERR
hibaval ter vissza. Vegul egy M_FLUSH uzenet lesz a lefele men} streamen elkuldve.
o
M_ERROR

es M_PCSIG : Signalokat lehet a stream-fejen keresztul bizonyos (peldaul
signalokra varakozo) folyamatoknak kuldeni. Az M_PCSIG a magas prioritasu.
M_SIG

: Egy streamen lev} modulok mindegyiket arra utas tja, hogy a queueo
jaikat ur tsek ki. Minden modulnak es drivernek kezelnie kell ezt az uzenetet.
(Erre megoldast jelent peldaul a kernel flushq() rutinjanak a megh vasa.) Ez egy
magas prioritasu uzenet.
M_FLUSH

8.1.5 Egy STREAMS-et hasznalo program
A kovetkez} program az el}bbieknek a hasznalatat mutatja be - inkabb a programozo
o
o
szemszogeb}l. A program el}szor megnyitja a /dev/bcndm0 STREAMS drivert, rahelyezi
o
o
a birk nev} STREAMS modult, majd ezen I/O m}veleteket vegez. (A modul ill. driver
u
u
implementacioja kes}bb lesz ismertetve.) Ez azt jelenti, hogy a megnyitott leba rt
o
illetve az onnan beolvasott adatok (uzenetek) keresztulmennek a birk nev} modulon is,
u
ami a feladatanak megfelel} dolgokat elvegezheti rajtuk. Lathato, hogy a kernelben
o
lev} modulokat nevukkel lehet azonos tani (a modulnevek bekerulnek egy fmodsw kernel
o
tablazatba). A program vegul leveszi a driverr}l a birk nev} modult, es lezarja a mego
u
nyitott let.
A kovetkez} abra bemutat egy streamet az I_PUSH el}tt es utan.
o
o
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PUSH

write queue

read queue

-

Stream-fej

6
q-next

write queue
q-next

q-next
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?

q-next

write queue

?
read queue

STREAMS
Driver

read queue
q-next

q-next
write queue

read queue

6

?
write queue

#include <stropts.h>
#include <fcntl.h>

/* Konstansok miatt kell */

main()
{
char buf 512]
int fd,count

read queue

/* STREAMS pelda */

/* Driver megnyitasa : */
if ((fd=open("/dev/bcndm0",O_RDWR)) == -1 )
{ perror("/dev/bcndm0") exit(1) }
/* Modul rahelyezese : */
if (ioctl(fd,I_PUSH,"birk") == -1)
{ perror("Push birk") exit(2) }
while ((count = read(0,buf,512) ) > 0) /* STANDARD inputrol olvas */
if (write(fd,buf,count) != count)
{ perror("/dev/bcndm0") exit(3) }
/* Modul leszedese : */
if (ioctl(fd,I_POP,0) == -1)
{ perror("Pop birk") exit(2)
close(fd)
}

}
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8.1.6 Az ide tartozo rendszerh vasok
Ebben a pontban fel vannak sorolva azok a UNIX rendszerh vasok, amelyek felhasznaloi
szinten kapcsolodnak a STREAMS-hez. Ezek le rasanak a tanulmanyozasa hasznos lehet.
open(2)

: STREAMS device driverre vonatkozo le megnyitasa

close(2)
read(2)

: STREAMS le lezarasa

: Adatok olvasasa egy lebol

write(2)

: Adatok rasa egy leba
:

h vasok. A STREAMS rendszer specialis ioctl h vasairol lasd a
-et is.

ioctl(2) ioctl
streamio(7)
getmsg(2)

: Uzenet fogadasa egy streamb}l
o

putmsg(2)

: Uzenet rasa egy streamre

poll(2)

: STREAMS leon input/output multiplexeles

8.2 A STREAMS driverek felep tese
Ebben a fejezetben ismertetve lesz az, hogy hogyan es mit kell tudnia egy STREAMS device drivernek. Majd bemutatunk egy egyszer} STREAMS device drivert, es ket szinten
u
egyszer} szerkezet} STREAMS modult. A driver egy tetsz}leges nagysagu csak rhato
u
u
o
memoriat biztos t a programozonak. Vagyis a hozza erkez} uzeneteket mind eldobja,
o
mint a /dev/null UNIX device driver. A modulok kozul az egyik egy olyan modul lesz,
amely nem valtoztatja meg a rajta atmen} adatokat - olyan, mintha ott se lenne. A
o
masik modulnak kicsit tobb a haszna, a nyomkovetesnel jol lehet hasznalni. A rajta
atmen} uzenetek hexa dumpjat rja ki.
o

8.2.1 Mire kell vigyazni egy driver kesz tesekor
A driverek logikailag a kernel legalso szintjen vannak, ezert azok rasakor kulonosen
vigyazzunk a kovetkez}kre :
o
A driverek teljesen a kernelben dolgoznak, ezert a kis hibak is a UNIX rendszer
leallasat vonhatjak maguk utan.
A driverek nem hasznalhatnak rendszerh vasokat, es mas ezekre epul} konyvtari
o
rutinokat.
A driverekben nem lehet a standard lebeg}pontos aritmetikat hasznalni.
o
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8.2.2 STREAMS szolgaltatasok

A STREAMS driverekben a driver megnyitasat, az adatok tovabb tasat es a driver
lezarasat mas-mas eljaras vegzi. Ezeket az eljarasokat a kernel a neki atadott
tablazatok alapjan tudja elerni, es amikor vegrehajtja }ket, akkor parameterkent atad az
o
eljarasoknak informaciokat, ami megkonny ti a munkajukat. A leggyakrabban hasznalt
rutinok es feladatuk le rasa a kovetkez} pontok temaja.
o
Altalaban kulon eljarasokat rhatunk a lefele es a felfele halado streamhez, de rhatunk a
ket stream altal kozosen hasznalt rutint is. Ha valamelyik szolgaltatasra nincs szukseg,
akkor azt nem kell kodolni (ld. kes}bb).
o

Driver/modul megnyitasa (open)
Szintaxis :
int xxopen(queue_ptr,dev,flag,sflag)
queue_t *queue_ptr
/* A read-queuera a pointer */
dev_t dev
int flag,sflag

Ez a rutin STREAMS drivereknel a driver megnyitasanal, a STREAMS moduloknal
a modulra vonatkozo I_PUSH h vasnal lesz vegrehajtva. A hagyomanyos UNIX device
driverekhez hasonloan ennek az eljarasnak inicializalasi feladatai vannak. A queue_ptr
parameter az uj streamre egy pointer. A dev parameter a device numbert tartalmazza, a
flag parameter megegyezik a hagyomanyos UNIX device drivereknel hasznalt flag-gel
jelolt parameterrel (open agek, ld. oflags az open rendszerh vas parameterei kozott). A
dev parameter mind a major mind a minor device numbert tartalmazza. Ha szuksegunk
van ezek kozul valamelyikre, akkor az a major() illetve minor() kernel segedrutinnal
(legtobb helyen ez egy makro) kinyerhet} a dev parameterb}l. Az sflag a stream mego
o
nyitasanak specialis jellemz}it tartalmazza. Erteke lehet :
o
0 : normal open-nel lesz megh vva, vagyis amikor egy STREAMS driverre utalo
spcialis let nyitunk meg. Ekkor a dev-ben megadott minor device number a lerendszerb}l kinyert szam lesz.
o
MODOPEN : Modulkenti megnyitaskor lesz megh vva.
CLONEOPEN : Clone-driver t pusu megnyitast jelzi. Ekkor nem lesz atadva a dev
parameterben ervenyes minor device number, hanem a drivernek maganak kell egy
bels} tablazatabol egy minor device numbert a h vo programnak adni.
o
Az, hogy egy driver hogyan lesz megnyitva, vagyis az sflag=0 lesz vagy
sflag=CLONEOPEN lesz, az a /dev directoryban lev} specialis lera utalo bejegyzes taro
talmatol fugg. A clone-drivernek a major device numberja 63 legyen (SINIX rendszerben
a clone driver major device numberja pont 63), a minor device numberje pedig legyen
egyenl} az igazi device major device numberjevel. Ett}l fuggetlenul csinalhatunk meg
o
o
tobb directory-bejegyzest is a lerendszerbe az igazi driver sajat major es minor device numberjeivel. Ezekkel az egyes minor device-okat direkt el tudjuk erni (ha peldaul
csak a kontroller 2. portja jo nekunk, akkor azt). Erre lathatunk peldat a kovetkez}
o
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tablazatban.
Drivernev Major device nr Minor device nr Megjegyzes
clone
63
0
Clone-driver
x0
40
0
Kontroller 0. portja (direkt)
x1
40
1
Kontroller 1. portja (direkt)
...
..
..
..
xcln
63
40
Kontroller a Clone-driveren keresztul
Ha az xcln let megnyitjuk, aminek a major device numberje egyenl} a clone driver major
o
device numberjevel, akkor a clone driver lesz el}szor vegrehajtva, es (mint egy diszpecser)
o
keres egy ures minor devicet, es ezt adja tovabb a driver open rutinnak. A megnyito rutin
egy nulla visszateresi ertekkel jelzi, ha nem volt hiba a futasa kozben, vagy OPENFAIL
ertekkel terjen vissza, ha a megnyitas eredmenytelen volt. Az open es a close rutinok
vegrehajtasakor a kernel lokkolja a device i-nodejat, gy egyszerre csak egy open vagy
close rutin lehet akt v major/minor deviceonkent. Megjegyzes: Ha a felhasznaloi programokbol
megnyitjuk egy STREAMS device driver valamelyik minor device-jat, majd kes}bb ismet kiadunk egy open
o
rednszerh vast ugyanarra a minor devicera, akkor a masodik open rendszerh vasnal az open rutin nem lesz ujra
megh vva.

Driver/modul lezarasa (close)
Szintaxis :
xxclose(queue_ptr)
queue_t *queue_ptr

/* Pointer a read queuera */

A rutin a STREAMS driverre vonatkozo close rendszerh vasnal es az I_POP ioctl
h vasnal lesz vegrehajtva. Ezutan a felhasznaloi program mar nem tudja elerni a device drivert (vagy modult). Sikeres vegrehajtas eseten a visszateresi ertek: 0, sikertelen
vegrehajtas eseten pedig az errno valtozoba rakando ertek legyen. Megjegyzes: a close rutin
csak akkor lesz megh vva, amikor az adott minor devicera vonatkozo legutolso let is lezartak.

Uzenet fogadasa (put rutin)
Szintaxis :
int xxput(qp,mp)
queue_t *qp
mblk_t *mp

Ez az eljaras akkor lesz vegrehajtva, amikor a drivernek (vagy modulnak) adatot
kell fogadnia a qp parametereben megadott streamr}l. A mp parameter a beerkezett
o
uzenetre pointer. Az uzenetet vagy el kell dobnia, vagy modos tva tovabb kell
adnia. Ha tovabbadja, akkor vagy egy sajat soraba (putq() fuggvennyel), vagy a streamen lev} kovetkez} modulnak (putnext() makroval), vagy pedig az ellenkez} iranyu
o
o
o
sorba (qreply() fuggvennyel) adhatja tovabb. Ha egy sajat soraba adja tovabb, akkor
az uzenet meg atmegy egy service rutinon is (ld. kes}bb). Az uzenettovabb tas altalaban
o
az uzenetre mutato pointer tovabbadasat jelenti.
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A service rutin
Szintaxis :
int xxsrv(qp)
queue_t *qp

A service rutin csak a sajat sorara mutato pointert kapja meg parameterkent. A
fuggvennyel tudja a sorabol a kovetkez} uzenetet megszerezni, majd ezutan ha
o
tudja, akkor tovabbadhatja a streamen kovetkez} modulnak. Ez alapjan egy service
o
rutin vazlatos felep tese a kovetkez} lehet :
o
getq

int xxsrv(qp)
queue_t *qp
{
/* Lokalis deklaraciok - reentrans kod erdekeben */
mblk_t *mp
while (mp=getq(qp) != NULL)
{
if (canput(qp->q_next) || (a message magas prioritasu))
{
dolgozd_fel_az_uzenetet()
if (tovabb_kell_adni_az_uzenetet())
{
putnext(qp,mp)
}
} else {
putbq(qp,mp)
return
}
}
}

Az uzenett pusok ertekei ugy vannak kiosztva, hogy azok az uzenetek alacsony prio
oritasuak, amelyeknek adatblokkjaban a db type mez} erteke QPCTL-nel kisebb (a
QPCTL makro a sajat operacios rendszerunk valamelyik header le-jaban van de nialva).

Service rutin vs. put rutin

A service rutin opcionalis, csak akkor szukseges, ha a put rutin az uzenetet nem tudja
a beerkezesenek " pillanataban " rogton feldolgozni (mert peldaul a hardware periferia
meg nem ert el egy bizonyos bels} allapotot) vagy a stream mar tul van terhelve es nem
o
fer bele az uzenet. Minden modulhoz es driverhez meg lehet adni egy low water mark es
egy high water mark erteket. Ez azert jo, mert el lehet vele erni egy nagyjabol egyenletes
adataramlast (nem alakul ki adatdugo). Ha az uzenetek altal lefoglalt byte-ok szama
meghaladja a modulhoz megadott high water mark erteket, akkor egy QFULL ag be lesz
all tva. Ennek a agnek az allapotat az el}tte lev} modul a canput kernelfuggvennyel
o
o
lekerdezheti, es ha a ag be van all tva, akkor normal (alacsony) prioritasu uzeneteket
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mar nem adhat tovabb. (Ezeket a sajat soraba visszarakhatja a putbq STREAMS kernel
segedfuggvennyel.) A service rutinra csak akkor jut a vezerles, ha az addig ures sorba
egy uj uzenet kerult, vagy az alatta kovetkez} modulban elerte az uzenetek altal lefoglalt
o
byte-ok szama a low water markot. Ezen k vul maskor is megkaphatja a vezerlest, de
err}l sajat maganak kell gondoskodnia (a qenable es az enableok STREAMS kernel
o

?

put
?
service

?

put
?
service
segedrutinok seg tsegevel).

?

6
-

put
6
service

6

-

put
6
service

6

Driver ioctl rutin
A hagyomanyos karakteres UNIX device driverekben egy kulon belepesi pont az ioctl
h vasokat feldolgozo eljaras. Ezzel szemben a STREAMS device driverek eseteben az
ioctl h vasokat tobbnyire a stream-fej dolgozza fel, azokbol bizonyos t pusu uzeneteket
general, ami le lesz kuldve a STREAMS drivernek (vagy modulnak). Az I_STR h vas
peldaul arra utas tja a stream-fejet, hogy egy M_IOCTL t pusu uzenetet kuldjon le a streamen. Ekkor az ioctl h vasok feldolgozasa az M_IOCTL t pusu uzenetek driveren beluli
feldolgozasat jelenti.

8.2.3 Kritikus szakaszok vedelme
Gyakran szukseg van arra, hogy am g egy bonyolultabb adatstrukturat egy STREAMS
driveren vagy modulon belul megvaltoztatunk, addig letiltsuk a megszak tasokat. Peldaul
azert, mert ha a driver az adatstruktura modos tasat nem fejezte be, es a m}kodeset
u
megszak tja egy masik driver, amely az inkonzisztens allapotban lev} adatstrukturat
o
tudja csak modos tani, akkor az egesz rendszer epsege veszelyeztetve van. A kritikus
szakasz elejen az interruptokat az splstr() h vassal lehet letiltani, a visszateresi erteket
a kritikus szakasz vegeig kell eltarolni. A kritikus szakasz vegen vissza kell all tani a
processzor interrupt prioritasi szintjet az splx() kernel h vas seg tsegevel a kritikus szakaszba belepes el}tti szintre. Ez vazlatosan a kovetkez}kepp oldhato meg:
o
o
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rutin()
{
int regispl
...
regispl=splstr()
...
/* Kritikus szakasz */
...
splx(regispl)
...
}

8.2.4 Fontosabb adatszerkezetek
A kovetkez}kben ismertetett adatstrukturak altalaban minden STREAMS driverben
o
megvannak. Azert fontosak, mert a kernel ezek alapjan talalja meg a driver kulonfele
szolgaltatasait vegz} eljarasait.
o

A modul informacios struktura
Ez a struktura az egyes stream sorok jellemz}it tartalmazza. A felep tese a kovetkez}
o
o
(ISC UNIX 3.2 alapjan) :
struct module_info {
ushort mi_idnum
char *mi_idname
short mi_minpsz
short mi_maxpsz
ushort mi_hiwat
ushort mi_lowat
}

Az mi_idnum mez} tartalmazza a modul azonos toszamat. A mi_idname mez} taro
o
talmazhatja a modul nevere (egy stringre) mutato pointert (a kernel ez alapjan a nev
alapjan meg tudja talalni). A mi_minpsz es a mi_maxpsz mez}k a modul altal elfogadott
o
uzenetek minimalis illetve maximalis meretet szabjak meg. Ezek a mez}k mindig csak a
o
stream-fejhez legkozelebb lev} STREAMS modulnal erdekesek, mert a STREAM-fej ugy
o
fogja a lefele kuldott adatokat uzenetekre szetvagni, hogy az egyes uzenetek merete a
megadott minimalis es maximalis uzenetmeret koze essen. A legfels} modul alatti modo
ulokban megadott maximalis es minimalis uzenetmeretet a STREAMS rendszer nem
hasznalja semmire, a programozo maga donti el, hogy valamire akarja-e azt hasznalni.
A maradek ket mez} a low ill. high water mark ertekeket tartalmazzak. Ezeknek az
o
ertekeknek a kivalasztasakor gyelembe kell venni azt, hogy a stream-fej a 64 bytenal
rovidebb uzeneteknek is 64 byteot foglal le, nehogy a STREAMS rendszer rendelkezesere
allo memoria tulsagosan feldarabolodjon.
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A qinit struktura

Ebben a strukturaban kell tarolni azt, hogy az egyes soroknak a szolgaltatasait melyik
eljarasokban kodoltuk. A struktura felep tese a kovetkez} :
o
struct qinit {
int
(*qi_putp)()
/*
int
(*qi_srvp)()
/*
int
(*qi_qopen)()
/*
int
(*qi_qclose)()
/*
int
(*qi_admin)()
/*
struct module_info *qi_minfo
struct module_stat *qi_mstat
}

put eljarasra mutat */
service eljarasra mutat */
open ill I_PUSH eseten meghivva */
lezarasnal meghivva */
3bnet admin funkcioja */
/* module_info struktura */
/* statisztikai struktura */

Ezt a strukturat a driveren belul nem szabad megvaltoztatni (mivel ez masokra
is kihatassal lenne). Az open es close rutinokra mutato pointerek a read qinit strukturaban legyenek, mivel a rendszer mindenkeppen azokat hajtja vegre. (Erdemes a write
oldalra a konnyebb olvashatosag erdekeben ugyanezeket az eljarasokat bejegyezni.)

A streamtab struktura

Ez a struktura tartalmazza a driverek read ill. write queue-jainak a qinit strukturaira
mutato pointert. Felep tese :
struct streamtab {
struct qinit *st_rdinit
struct qinit *st_wrinit
struct qinit *st_muxrinit
struct qinit *st_muxwinit
}

/*
/*
/*
/*

Felso read queue */
Felso write queue */
Also read queue */
Also write queue */

Az also soroknak csak a multiplexer drivereknel van szerepuk.

8.2.5 Tovabbi hasznos tanacsok

A kovetkez} szabalyokat erdemes betartani a rendszer konzisztenssegenek megtartasa
o
erdekeben.

STREAMS device driverek kesz tesenel

Azokat az uzeneteket, amikkel a driver nem tud mit kezdeni, el kell dobni
(freemsg() kernel h vas seg tsegevel).
A drivernek fel kell dolgoznia minden M IOCTL uzenetet. Ha ez nem tortenik
meg, akkor a STREAM-fej (esetleg vegtelen sokaig) leblokkol, mert hiaba var az
ioctl() h vas nyugtazasara.
Ha egy driver nem tud mit kezdeni egy M IOCTL uzenettel, akkor azt egy
M IOCNAK uzenettel nyugtazza. Ez az eset peldaul akkor fordulhat el}, ha el ras
o
vagy egyeb felhasznaloi programbeli hibak miatt a drivernek rossz (esetleg mas
drivereknek szant) M IOCTL uzenetek lesznek atadva.

8.2. A STREAMS DRIVEREK FELEP TESE

149

STREAMS modulok kesz tesenel
Azokat az uzeneteket, amik nem a modulnak szolnak, valtoztatas nelkul tovabb
kell adni.
A modulnak szolo M IOCTL uzeneteket feldolgozasuk utan a modulnak nyugtaznia
kell vagy egy M IOCACK vagy pedig egy M IOCNAK t pusu uzenettel. (Azokat az
M IOCTL uzeneteket, amelyek nem a modulnak szolnak, valtoztatas nelkul tovabb
kell adni.)

Megjegyzesek a peldadriverhez
A driverben csak a write queue-hoz tartozo put eljaras van implementalva - a tobbi
szolgaltatas helyen a nulldev eljaras c me van. Ez az eljaras a kernelben egy ures
eljaras. C nyelven kb. a kovetkez} lehet :
o
nulldev()
{
}

A kernelt disassemblalva a kovetkez} assembly sorok tartoznak ehhez az eljarashoz
o
(INTERACTIVE 3.2 UNIX alapjan) :
nulldev()
pushl %ebp
movl %esp,%ebp
leave
ret

A nulldev eljaras mellett letezik egy nodev nev} is, amit hasonlo esetekben
u
hasznalhatunk. A kett} kozott a kulonbseg az, hogy a nulldev- vel kodolt szolgaltatast
o
kivalto rendszerh vas a sikeres vegrehajtasanak megfelel} visszateresi erteket ad vissza,
o
m g a nodev-vel jelolt szolgaltatasokat igenybe vev} rendszerh vasok hibakoddal ternek
o
vissza.

8.2.6 A driver hibauzenetei
A device driverekben ( gy a STREAMS driverekben is) a hibauzeneteket a cmn_err()
kernel rutin seg tsegevel lehet ki rni - ennek reszletesebb le rasat lasd az altalanosan
hasznalhato kernel rutinokrol szolo reszben. Helyrehozhatatlan hibak eseten ez a rutin
viszi a UNIX rendszert a panic allapotba, ami vegs} soron a processzor shutdown
o
allapotba rakasat jelenti. A cmn_err() kernel h vas szintaxisa a kovetkez}:
o
#include "sys/cmn_err.h"
int cmn_err(severity, format, arguments)
char *format
int severity, arguments
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8.2.7 A driver listaja
#include <sys/types.h>
#include <sys/stream.h>
#include <sys/cmn_err.h>
#define NULL
((char *)(0))
extern nulldev()
static int bcndput(), bcndopen(), bcndclose()
static struct module_info modinfo =
/* A stream queue jellemzoit irja le */
{ 0,
/* Modulazonosito szam - itt nem fontos */
(char *)0, /* Modul neve - itt nem fontos */
0,
/* Minimalis message-meret */
INFPSZ,
/* Maximalis message-meret - INFPSZ=vegtelen */
0, 0
/* High low water mark 0=nincs ellenorzes */
}
static struct qinit bcndwinit =
/* "write" queue - lefele halado adatok */
{ bcndput, /* A message feldolgozasat vegzo eljaras */
nulldev,
/* Service procedure - itt nincs */
bcndopen, /* open-nel ill. PUSH-nal meghivott rutin */
bcndclose, /* utolso close-nal vagy pop-nal vegrehajtva */
nulldev,
/* admin bejegyzes (csak a 3bnet-hez kell) */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat */
}
static struct qinit bcndrinit =
/* "read" queue - felfele halado adatok */
{ nulldev,
/* Errol a driverrol nem fognak olvasni */
nulldev,
/* Service proc. nincs */
bcndopen, /* open-nel, PUSH-nal meghivott rutin */
bcndclose, /* utolso close-nal vagy pop-nal meghivott r. */
nulldev,
/* admin bejegyzes */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat cime */
}
struct streamtab bcndinfo =
/* A kernel ez alapjan tud tajekozodni a driverben */
{ &bcndrinit, /* Read queue-rol informaciok */
&bcndwinit, /* Write queue-rol informaciok */
NULL,
/* Multiplex. read queue */
NULL
/* Multiplex write queue */
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}
static int bcndput(q,mp)
/* "write" rutin */
queue_t *q
/* Pointer a WRITE-queue-ra */
mblk_t *mp
/* Az adatblokkra pointer */
{
cmn_err(CE_CONT, "bcndput... " ) /* Nem lesz ujsor kiirva ... */
freemsg(mp) /* Visszaadjuk a rendszernek a stream-fej altal
az uzenetnek lefoglalt memoriateruletet */
}
static int bcndopen(q, dev, flag, sflag)
queue_t *q
dev_t
dev
int
flag,sflag
{
cmn_err(CE_NOTE, "bcndopen" )
return 0
}
static int bcndclose(q)
queue_t *q
{
cmn_err(CE_NOTE, "bcndclose" )
return 0
}

8.2.8 A driver kernelbe linkelese

A UNIX kernel bizonyos fokig modularis szerkezet}. Van egy (nagy) kozponti resze
u
(ennek neve: os.o, merete az Siemens i486 Release 4 UNIX eseten kb. 1.5 MByte),
es vannak egyeb kiegesz tesek, ilyenek peldaul a tobbfele (0.5K, 1K, 2K) lesystemek,
az ATT xt driver. Nem minden UNIX kon guracio alatt van szukseg az osszes ilyen
kiegesz t} driverre (az xt driverre pl. csak akkor, ha olyan specialis terminalokkal reno
delkezunk, ami ezt kihasznalhatja). Azt, hogy az aktualis UNIX software-kon guracio
ezek kozul mit tartalmaz az un. master leokban van le rva. Ket ilyen master le van: az
egyik az mdevice, a masik az sdevice. Mindkett} le a /etc/conf/cf.d directoryban
o
talalhato.
Ezeknek a leoknak a pontos szerkezeter}l a man paranccsal nyerhetunk pontosabb ino
formaciokat. Itt csak a legalapvet}bb tudnivalok lesznek ismertetve, ami a STREAMS
o
drivereknel fontos. Az mdevice le tartalmazza az osszes letez} driver le rasat, az
o
sdevice le pedig az aktualis kon guraciot rja le.

Az mdevice le

Az mdevice lebol egy reszlet (a fejlec nem tartozik a lehoz!):
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Device Funkciok Karakte- Prefix Block
Char.
Min. Max.
name listaja risztika
major nr. major nr. unit unit
tape
ldterm
ptem
timod
tirdwr
udp

ocrwi
I

Devicename

lehet.

ioc
Si
Si
Si
Si
iSco

tape_
ldtr
ptem
tim
trw
udp

0
0
0
0
0
0

41
0
0
0
0
29

0
1
1
1
1
1

1
32
32
4
8
256

DMA
channel
-1
-1
-1
-1
-1
-1

: Ez a device (vagy a modul) bels} neve. Maximum 8 karakter hosszu
o

: Ez a mez} egy vagy tobb karaktert tartalmazhat, amely a meglev}
o
o
szolgaltatasokat rja le ha egyik szolgaltatas sem letezik, akkor egy minusz jelet kell ide rakni). A driver szolgaltatasok tobbek kozt a kovetkez}k (err}l
o
o
reszletesebben lasd a megfelel} UNIX referencia kezikonyveket) :
o
Funkciolista
driver

{
{
{
{
{
{
{

: open rutin
c : close rutin
r : read rutin
w : write rutin
i : ioctl rutin
s : startup rutin
I : init rutin
Karakterisztika : Ez a device egyes jellemz}it tartalmazza. Itt csak a fontosabo
bak lesznek megeml tve :
{ i : A device driver installalhato.
{ c : A device egy karakteres eleres} egyseg.
u
{ b : A device blokk eleres}.
u
{ o : Ehhez a devicehoz csak egy sdevice beli sor tartozhat.
{ S : Ez STREAMS jelleg} driver ill. modul.
u
{ r : Erre a devicera szukseg van meg a legminimalisabb kernel kon guracioban
is.
A STREAMS device drivereknel itt az Sc betuknek el} kell fordulniuk. Azoknal a
o
STREAMS moduloknal, amelyek egyben nem device driverek : c betu ne forduljon
el}!
o
Prefix : Ez a mez} tartalmazza azt a szoveget, ami alapjan a kernel megtalalja a
o
belepesi pontokat tartalmazo tablazatot. (STREAMS drivernel: ha a streamtab
strukturanak a neve (mint a peldaban) : bcndinfo, akkor ez a mez} bcnd szoveget
o
tartalmaz.
o
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: A legtobb esetben ennek a mez}nek a tartalma legyen 0, mert
o
a device numberek az installalaskor az idinstall vegrahajtasakor lesznek kiosztva.
Char major nr. : Ld. a Block major nr. mez}t.
o
Min. unit : Ez tartalmazza azt a minimalis szamot, amit az sdevice tartalmazhat
az unit mez}ben.
o
Max. unit : Ez tartalmazza azt a maximalis szamot, amit az sdevice maximum
tartalmazhat az unit mez}ben.
o
DMA channel : Itt lesz megadva, hogy a device melyik DMA csatornat hasznalja.
Ha a device nem hasznal DMA csatornat, akkor ide -1 kerul.
Block major nr.

Az sdevice le

Az sdevice lebol egy reszlet (a fejlec nem tartozik a lehoz!):
Device Con
Unit Ipl
name figure
tape
ldterm
ptem
timod
tirdwr
udp

N
Y
Y
Y
Y
Y

1
16
16
1
1
256

0
0
0
0
0
0

Type

Vector

0
0
0
0
0
0

0
0
0
0
0
0

SIOA

0
0
0
0
0
0

EIOA

SCMA

0
0
0
0
0
0

0
0
0
0
0
0

ECMA

0
0
0
0
0
0

Ez a le tartalmazza azt, hogy az mdevice leban speci kalt deviceok kozul az
aktualis kon guracioba mely driverek kerultek bele, es melyek nem. Ez a le az
/etc/conf/sdevice.d directoryban lev} komponensekb}l lesz osszeall tva. (A fenti dio
o
rectoryban lev} leokat vagy a rendszerrel szall tottak, vagy kes}bb lett installalva az
o
o
idinstall paranccsal.) A le bejegyzesei a kovetkez}k :
o
: A driver bels} nevet tartalmazza. Valamelyik mdevice bejegyzes
o
nevevel meg kell egyeznie.
Configure : Ez a mez} 'Y'-t tartalmazzon akkor, ha installalni kell a kernelbe,
o
egyebkent 'N'-et.
Unit : Ez az ertek a device driver altal vezerelhet} aldevice-ok szamat tartalmazza.
o
(Maximalis es minimalis erteke az mdevice leban van feltuntetve.)
Ipl : Ez a mez} azt hatarozza meg, hogy a driver interrupt rutinja mely rendszer
o
ipl (ipl=interrupt priority level) szinten fusson. Erteke 0 es 8 kozt lehet. Ha a
drivernek nincs interrupt rutinja, akkor ebbe a mez}be 0 keruljon.
o
Type : Ez a mez} tartalmazza az interruptkiosztas modjat. Ertekei itt nem lesznek
o
megnevezve. Ha a driver nem tartalmaz interrupt rutint, akkor ide 0 keruljon.
Device name
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: Ez a mez} a devicehoz rendelt interrupt vektor (sor-)szamat tartalmazza.
o
Ha a devicehoz nem tartozik interrupt vektor, akkor e mez} erteke 0 legyen.
o
SIOA : A Start I/O Addresst tartalmazza a mez}. Ha ilyen dolog nem tartozik a
o
driverhez, akkor erteke 0 legyen.
EIOA : Az End I/O Addresst tartalmazza a mez}. Ha ilyen dolog nem tartozik a
o
driverhez, akkor erteke 0 legyen.
SCMA : A Start Controller Memory Addresst tartalmazza a mez}. Ha ilyen dolog
o
nem tartozik a driverhez, akkor erteke 0 legyen.
ECMA : Az End Controller Memory Addresst tartalmazza a mez}. Ha ilyen dolog
o
nem tartozik a driverhez, akkor erteke 0 legyen.
Vector

8.2.9 Driver installalas ISC UNIX alatt

Ha egy device drivert elkesz tunk, akkor azt egy specialis (Driver Software Packagenek nevezett) formaban terjeszthetjuk peldaul magneslemezen. Az INTERACTIVE UNIX az ilyen formatumu device drivereket automatikusan tudja installalni, ez
nagy konnyebbseg a felhasznalonak. (Err}l a formatumrol az INTERACTIVE UNIX
o
le rasaban olvashatunk.) De a driver fejlesztesenel eleg hosszadalmas munka lenne minden egyes tesztverzional egy DSP formatumu lemezt letrehozni, ezert a kovetkez}kben
o
bemutatjuk a driver installalasanak manualis valtozatat. Ehhez altalaban a root neven
kell bejelentkezni.

Objectkod letrehozasa

Ha a driverunk forraskodja egyetlen C nyelv} programbol all (ennek neve legyen most
u
Driver.c, akkor azt a szokasos modon a
cc -c Driver.c

UNIX parancs seg tsegevel ford thatjuk le. (Barmi lehet a driver neve, csak az a
fontos, hogy a keletkezett objectkod at legyen majd nevezve a Driver.o nevre.) Ha
viszont a driver forraskodja tobb C nyelv} programbol all, akkor azokat egyenkent a
u
fenti modon kell leford tani, es az ld -r paranccsal az gy keletkezett objecteket lehet
egy modulla osszeszerkeszteni, aminek a neve legyen Driver.o.

Master leok valtoztatasa

Adni kell a drivernek egy nevet. (Peldaul a master leokban ez a nev fogja azonos tani a
drivert. A peldadriverunknel legyen ez a nev:bcnd, ezt a nevet hasznaljuk a tovabbiakban
is.)
Krealni kell egy system le bejegyzest (ez kerul az sdevice leba) a kovetkez}kepp:
o
az /etc/conf/sdevice.d directoryban hozzunk letre szovegszerkeszt}vel egy bcnd nev}
o
u
let. Ebbe rjuk a driverhez tartozo sdevice bejegyzest. Legyen ez peldaul a kovetkez}
o
:
bcnd

Y

1

0

0

0

0

0

0

0
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Az mdevice let szinten ki kell egesz teni. Ez ugy megy, hogy az aktualis directoryban
letre kell hozni egy Master nev} let, ami az uj mdevice bejegyzest tartalmazza. Legyen
u
ez a kovetkez} :
o
bcnd

-

Sic

bcnd

0

0

1

4

-1

A kovetkez} UNIX shell parancs megvaltoztatja az mdevice let (ugy, hogy a Master
o
let az aktualis directorybol torli). (A le rasban van az, hogy a Master nev} let a
u
rendszer torli az aktualis directorybol, amikor a peldadrivereket beraktam a rendszerbe,
akkor nekem nem torolte le ezt a let.)
/etc/conf/bin/idinstall -a -m -k bcnd

Ezutan az /etc/conf/cf.d/mdevice leban nezzuk meg a blokk/karakteres major
device numbert, kes}bb meg szukseg lesz ra.
o

Specialis le bejegyzese
Krealj egy bcnd nev} let a /etc/conf/node.d directoryban, es egesz tsd ki azt a Node
u
formatumnak megfelel}en. (Vagyis 4 mez} legyen egy rekordban, es az egyes mez}k
o
o
o
jelentese a kovetkez} :
o
1.: Driver neve (itt : bcnd)
2.: A device specialis lejanak a neve
3.: 'b' vagy 'c' bet} (blokk/character device drivernek)
u
4.: Minor device number)
A driverunknel ez a kovetkez}kepp nez ki :
o
bcnd

bcndm0

c

0

Tovabbi leok krealasa
Ha a drivert leteszteltuk, es mar hibatlanul m}kodik, akkor a /etc/conf/init.d,
u
a /etc/conf/rc.d es a /etc/conf/sd.d directorykat is a szukseges scriptekkel
kiegesz thetjuk.

A kernel ujralinkelese
Krealni kell egy /etc/conf/pack.d/bcnd nev} directoryt, es be kell vinni oda a
u
Driver.o es a Space.c nev} leokat, es csinalni kell egy masolatot a regebbi UNIX
u
kernelr}l a kovetkez} paranccsal :
o
o
cp /unix /unix.bak

Majd vegre kell hajtani a /etc/conf/bin/idbuild shell scriptet, ami ujralinkeli a
kernelt. Ha nem volt hiba, akkor shutdown utan a UNIX rendszert ujra betoltve tesztelhet} a driver. (A device specialis leok csak a kovetkez} UNIX reboot utan lesznek
o
o
megkrealva.)
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8.2.10 Meg egy pelda: a birka modul

A kovetkez} lista egy "birka" modul listajat tartalmazza. A modul nem bant semmit,
o
ami rajta atmegy (innen ered a neve is). A modul az uzenet tovabb tasahoz a putnext()
kernel makrot hasznalja.
#include <sys/types.h>
#include <sys/stream.h>
#include <sys/cmn_err.h>
#define NULL
((char *)(0))
extern nulldev()
static int birkwrite(), birkopen(), birkclose()
static struct module_info modinfo =
/* A stream queue jellemzoit irja le */
{ 0xa0,
/* Modulazonosito szam */
"birk",
/* Modul neve */
0,
/* Minimalis message-meret */
INFPSZ,
/* Maximalis message-meret - INFPSZ=vegtelen */
0, 0
/* High low water mark 0=nincs ellenorzes */
}
static struct qinit birkwinit =
/* "write" queue */
{ birkwrite, /* A message feldolgozasat vegzo eljaras */
nulldev,
/* Service procedure - itt nincs */
birkopen, /* open-nel ill. PUSH-nal meghivott rutin - comment */
birkclose, /* utolso close-nal vagy pop-nal vegrehajtva - comment*/
nulldev,
/* admin bejegyzes (csak a 3bnet-hez kell) */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat */
}
static struct qinit birkrinit =
/* "read" queue */
{ birkwrite, /* Message feldolgozasa */
nulldev,
/* Service proc. nincs */
birkopen, /* open-nel, PUSH-nal meghivott rutin */
birkclose, /* utolso close-nal vagy pop-nal meghivott r. */
nulldev,
/* admin bejegyzes */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat cime */
}
struct streamtab birkinfo =
/* A kernel ez alapjan tud tajekozodni a driverben */
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{ &birkrinit,
&birkwinit,
NULL,
NULL
}

/*
/*
/*
/*
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Read queue-rol informaciok */
Write queue-rol informaciok */
Multiplex. read queue */
Multiplex write queue */

static int birkwrite(q,mp)
/* "put" rutin */
queue_t *q
/* Pointer a WRITE-queue-ra */
mblk_t *mp
/* Az adatra pointer */
{
putnext(q, mp) /* A megkapott uzenet tovabbitasa */
/*
Ha a fenti sor helyett csak egy
freemsg(mp)
sor lenne, akkor ez a korabbi driver modul megfeleloje lenne
*/
}
static int birkopen(q, dev, flag, sflag)
queue_t *q
dev_t
dev
int
flag,sflag
{
/*
Mivel minden queuen egyforman nem csinal semmit a modul, ezert
nem kell semmi informaciot elrakni
*/
return 0 /* Minden O.K. */
}
static int birkclose(q)
queue_t *q
{
return 0 /* Minden O.K. */
}

8.2.11 Egy egyszer} debug modul
u

A kovetkez} lista egy "debug" modul listajat tartalmazza. A modul nem valtoztatja meg
o
a rajta atmen} adatokat, csak egy hexa dumpot r ki roluk a konzolra. Ha valahol arra
o
vagyunk k vancsiak, hogy mi megy keresztul egy streamen, akkor a k vant helyre be kell
illeszteni ezt a modult, es futas kozben elemezni kell az eredmenyeket.
#include <sys/types.h>
#include <sys/stream.h>
#include <sys/cmn_err.h>
#define NULL
((char *)(0))
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#define P_FELFELE 1
#define P_LEFELE 2
#define L_EGYSOR 16
extern nulldev()
static int dbugwrite(), dbugopen(), dbugclose()
static dumpmsg()
static struct module_info modinfo =
/* A stream queue jellemzoit irja le */
{ 0xa1,
/* Modulazonosito szam */
"dbug",
/* Modul neve */
0,
/* Minimalis message-meret */
INFPSZ,
/* Maximalis message-meret - INFPSZ=vegtelen */
0, 0
/* High low water mark 0=nincs ellenorzes */
}
static struct qinit dbugwinit =
/* "write" queue - lefele haladnak rajta az adatok */
{ dbuglput, /* Lefele meno adatok feldolgozasa */
nulldev,
/* Service procedure */
dbugopen, /* open-nel ill. PUSH-nal meghivott rutin - comment */
dbugclose, /* utolso close-nal vagy pop-nal vegrehajtva - comment */
nulldev,
/* admin bejegyzes (csak a 3bnet-hez kell) */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat */
}
static struct qinit dbugrinit =
/* "read" queue - felfele haladnak rajta az adatok */
{ dbugfput, /* Felfele meno adatok feldolgozasa */
nulldev,
/* Service proc. nincs */
dbugopen, /* open-nel, PUSH-nal meghivott rutin */
dbugclose, /* utolso close-nal vagy pop-nal meghivott r. */
nulldev,
/* admin bejegyzes */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat cime */
}
struct streamtab dbuginfo =
/* A kernel ez alapjan tud tajekozodni a driverben */
{ &dbugrinit, /* Read queue-rol informaciok */
&dbugwinit, /* Write queue-rol informaciok */
NULL,
/* Multiplexer read queue */
NULL
/* Multiplexer write queue */
}
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static int dbugfput(q,mp)
/* "put" rutin - felfele */
queue_t *q
/* Pointer a WRITE-queue-ra */
mblk_t *mp
/* Az adatra pointer */
{
dumpmsg(P_FELFELE,mp) /* Hexa dump */
putnext(q, mp) /* A megkapott uzenet tovabbitasa */
}
static int dbuglput(q,mp)
/* "put" rutin - lefele */
queue_t *q
/* Pointer a WRITE-queue-ra */
mblk_t *mp
/* Az adatra pointer */
{
dumpmsg(P_LEFELE,mp) /* Hexa dump */
putnext(q, mp) /* A megkapott uzenet tovabbitasa */
}
static int dbugopen(q, dev, flag, sflag)
queue_t *q
dev_t
dev
int
flag,sflag
{
return 0 /* Minden O.K. */
}
static int dbugclose(q)
queue_t *q
{
return 0 /* Minden O.K. */
}
static dumpmsg(qdirection,mp)
int qdirection /* Melyik iranyba megy az uzenet? */
mblk_t *mp
/* Az adatra pointer */
{ mblk_t *aktmess /* Az aktualis uzenet */
register unsigned char *mitki /* A kiirando karakterre pointer */
int kiirtak /* Egy sorba mennyi karaktert irt ki */
aktmess=mp /* Feltehetjuk, hogy nem NULLpointer */
if (qdirection == P_LEFELE) cmn_err(CE_NOTE,"LEFELE: ")
if (qdirection == P_FELFELE) cmn_err(CE_NOTE,"FELFELE: ")
kiirtak=0 /* Eddig a sorba egy karaktert sem raktunk ki */
while (aktmess != NULL) {
mitki=aktmess->b_rptr
/* Az adatterulet kezdete */
while (mitki < aktmess->b_wptr) { /* Adatterulet vege */
cmn_err(CE_CONT," 0x%b", *mitki)
kiirtak=kiirtak+1
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mitki=mitki+1
if (kiirtak == L_EGYSOR) {
kiirtak=0
cmn_err(CE_CONT," \n")
}
}
aktmess=aktmess->b_cont

/* Betelt egy sor */

/* Folytatast is ... */

}
}

8.2.12 Flush kezelese a driverben

Az M FLUSH uzenetet minden olyan STREAMS modulnak es drivernek kezelnie kell,
amely service rutint hasznal. Az ilyen t pusu uzenetek indulhatnak a stream-fejt}l,
o
valamelyik modultol vagy a drivert}l. Az uzenethez tartozo adatblokk els} byteja a
o
o
kovetkez} ertekeket tartalmazhatja :
o
FLUSHR : A read queuet kell ur teni.
FLUSHW : A write queuet kell ur teni.
FLUSHRW : Mind a read, mind a write queuet ur teni kell.
o
A driverekben az M FLUSH uzenetek tovabb tasara a kovetkez} szabalyok vonatkoznak:
ha egy M FLUSH uzenet er a driverhez, es csak a FLUSHW ag van beall tva, akkor
a driver eldobhatja az uzenetet. Ha pedig az uzenetben be van all tva az, hogy a read
queuet ur teni kell, akkor a drivernek torolnie kell azt a reszt, amely arra utal, hogy a read
queuet ur teni kell, es gy kell visszakuldeni az uzenetet a read queuera. A stream-fejnel
minden pontosan az ellenkez}keppen tortenik: ha a read queuen folfele olyan M FLUSH
o
uzenet erkezik, melyben csak a FLUSHR ag van beall tva, akkor a stream-fej eldobja
az uzenetet. Ha pedig az uzenet arra utal, hogy a write queuet ur teni kell, akkor az erre
utalo ag torolve lesz, es a stream-fej az uzenetet visszakuldi a write queuen.

8.3 Egy STREAMS loopback driver
Az eddig bemutatott driverek nagyon egyszer}ek voltak. Ezek seg tsegevel meg lehetett
u
erteni, hogy hogyan illeszkednek a kernelbe a driverek, de a debug modul kivetelevel keves
haszna van ezeknek a moduloknak. Ebben a fejezetben bemutatunk egy olyan STREAMS
drivert, amelynek a feladata az, hogy a write queuen felulr}l erkez} adatokat visszakuldje
o
o
a read queuen. A kovetkez}kben az egyes fejezetek a driver egy-egy reszet mutatjak be,
o
es az eddig meg nem ismertetett, de lenyeges dolgok meg lesznek magyarazva, es egyben
peldat lathatunk arra, hogy hogyan kell az M FLUSH uzeneteket a drivereknek kezelni.
A driver bels} neve lpbk lesz.
o

8.3.1 Driver interface strukturak
#include <sys/types.h>
#include <sys/stream.h>
#include <sys/cmn_err.h>
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#include <sys/errno.h>
#include <sys/sysmacros.h>
#define NULL

((char *)(0))

extern nulldev()
static int lpbkwrite(), lpbkopen(), lpbkclose(), lpbkserv()
static struct module_info modinfo =
/* A stream queue jellemzoit irja le */
{ 0,
/* Modulazonosito szam */
(char *)0, /* Modul neve */
0,
/* Minimalis message-meret */
INFPSZ,
/* Maximalis message-meret */
1024, 512 /* High low water mark 0=nincs ellenorzes */
}
static struct qinit lpbkwinit =
/* "write" queue - lefele halado uzenetek queueja */
{ putq,
/* A message megy a service rutinnak */
lpbkserv, /* Service procedure */
lpbkopen, /* open-nel meghivott rutin */
lpbkclose, /* utolso close-nal lesz vegrehajtva */
nulldev,
/* admin bejegyzes (csak a 3bnet-hez kell) */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat */
}
static struct qinit lpbkrinit =
/* "read" queue */
{ nulldev,
/* Message feldolgozasa */
lpbkserv, /* Service procedure */
lpbkopen, /* open-nel meghivott rutin */
lpbkclose, /* utolso close-nal meghivott rutin */
nulldev,
/* admin bejegyzes */
&modinfo, /* Modulinformacios struktura */
NULL
/* Statisztikakat tartalmazo tablazat cime */
}
struct streamtab lpbkinfo =
/* A kernel ez alapjan tud tajekozodni a driverben */
{ &lpbkrinit, /* Read queue-rol informaciok */
&lpbkwinit, /* Write queue-rol informaciok */
NULL,
/* Multiplexer read queue */
NULL
/* Multiplexer write queue */
}

Itt erdemes megjegyezni azt, hogy ha a driver valamelyik queueja tartalmaz service
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rutint, es a put rutin azon a queuen nem csinalna semmit az uzenettel, csak tovabbadna,
akkor az ahhoz a sorhoz tartozo qinit strukturaban put rutinkent jegyezzuk be a putq()
kernel segedrutint. Itt kihasznaltuk azt, hogy a putq() egy fuggveny, es nem makro, ezert
a memoriabeli c mere hivatkozhatunk.

8.3.2 Tovabbi deklaraciok

Az lpbk struktura az egyes minor deviceok aktualis allapotat tartalmazza. Ennek ertekei
a kovetkez} lehet :
o
LPBKOPEN : A minor device mar meg van nyitva.
struct lpbk {
unsigned lpbk_state
queue_t *lpbk_rdq
}

/* minor device aktualis allapota */
/* a minor devicehoz tartozo queue */

/* A minor deviceok allapotat leiro konstansok */
#define LPBKOPEN 01
#define NLPBK

16

/* Maximalisan kezelheto minor deviceok szama */

struct lpbk lpbkmdev NLPBK]

/* Itt vannak az minor deviceok adatai */

/* A minor deviceok szama van itt elrakva */
int lpbkcnt = NLPBK
/* Loopback driver ioctl kodok */
#define
#define
#define
#define

I_NOARG
I_ERRNAK
I_ERROR
I_SETHANG

65
66
67
68

8.3.3 Loopback driver start rutinja

A driver adatstrukturait a UNIX rendszer betoltesenel inicializalni kell. Erre valo a
device driverek start rutinja. A start rutin nem a STREAMS driverek specialitasa minden drivernek lehet ilyen rutinja. A driverunknel ez a kovetkez}keppen nez ki:
o
lpbkstart()
{
int i

/* Nem lehet statikus! */

for (i=0 i<NLPBK i++) {
lpbkmdev i].lpbk_state=0
lpbkmdev i].lpbk_rdq =NULL
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}
}

Azt a kon guracios leokba is be kell jegyezni, hogy a driverhez egy start rutin is tartotik. A device driverekhez tartozhat meg inicializalo ugynevezett init rutin is. A start
es az init rutin kozt a kulonbseg az, hogy az init rutin a kernel memoria menedzserenek
(KMA - kernel memory allocator) elindulasa el}tt lesz vegrehajtva, gy csak a kuls}
o
o
hardware berendezes inicializalasara hasznalhato. Ezzel szemben a start rutin mar a
KMA elindulasa utan lesz vegrehajtva.

8.3.4 Loopback driver open rutin
lpbkopen(q, dev, flag, sflag)
queue_t *q
dev_t dev
int flag,sflag
{
struct lpbk *mdevp /* Aktualis minor device strukturara pointer */
if ((sflag != CLONEOPEN) && (sflag != 0))
return(OPENFAIL)
/* Csak CLONEOPEN megengedett */
/* Keresni kell egy nem hasznalt minor device numbert */
if (sflag == CLONEOPEN) {
for (dev = 0 dev < lpbkcnt dev++)
if (!(lpbkmdev dev].lpbk_state & LPBKOPEN)) /* Ha nem nyitott */
break
/* ... akkor ez kell nekunk */
}
if (sflag == 0) dev=minor(dev)
if ((dev < 0) || (dev >= lpbkcnt)) /* Van meg szabad minor device? */
return(OPENFAIL) /* NINCS ... */
mdevp = &lpbkmdev dev]
if (!(mdevp->lpbk_state & LPBKOPEN)) {
mdevp->lpbk_rdq = q
/* Ez egy tetsz. felhasznaloi struktura */
q->q_ptr = (caddr_t)mdevp
WR(q)->q_ptr = (caddr_t)mdevp
return(dev)
}
else
if (q != mdevp->lpbk_rdq)
return(OPENFAIL)
/* Valaki mar megnyitotta es */
/* meg dolgozik ezen a streamen */
}

8.3.5 Loopback driver close rutin
lpbkclose(q)
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queue_t *q
{

/* Allitsuk be, hogy a queue mar nincs hasznalva */
((struct lpbk *)(q->q_ptr))->lpbk_state &= \verb! !LPBKOPEN
((struct lpbk *)(q->q_ptr))->lpbk_rdq = NULL
flushq(WR(q), 1)
}

8.3.6 Loopback driver service rutin

A loopback driver service rutinja visszakuldi az M DATA, M PROTO, M PCPROTO
uzeneteket, az M IOCTL uzenetekben megkapott "parancsokat" vegrehajtja, kezeli az
M FLUSH uzeneteket, es az egyeb uzeneteket eldobja. Az M IOCTL uzenetek feldolgozasat egy kulon eljaras vegzi.
lpbksrv(q)
queue_t *q
{
mblk_t *bp
/* A q pointer mindenkeppen a write queuera mutasson */
q = ((q)->q_flag&QREADR ? WR(q) : q)
while ((bp = getq(q)) != NULL) {
if ((bp->b_datap->db_type) < QPCTL && !canput(RD(q)->q_next) ) {
putbq(q, bp) /* Nincs hely az alacsony priotitasu uzenetnek */
return
}
switch(bp->b_datap->db_type) {
case M_IOCTL: /* ioctl uzenetek */
lpbkioctl(q, bp)
break
case M_DATA:
case M_PROTO:
case M_PCPROTO:
qreply(q, bp) /* Vissza a masik queuen */
break
case M_FLUSH:
if (*bp->b_rptr & FLUSHW) {
flushq(q, FLUSHALL)
*bp->b_rptr &= \verb! !FLUSHW
}
if (*bp->b_rptr & FLUSHR)
qreply(q,bp)
else freemsg(bp)
break
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default:
freemsg(bp)
break
}
}
}
lpbkioctl(q, bp)
queue_t *q
mblk_t *bp
{
struct iocblk *iocbp
iocbp = (struct iocblk *)bp->b_rptr
switch(iocbp->ioc_cmd) {
case I_NOARG:
/*
* Minden OK, csak kuldjunk vissza egy visszajelzo uzenetet
*/
bp->b_datap->db_type = M_IOCACK
qreply(q, bp)
return
case I_ERROR:
/*
* Hibakodot is adjunk vissza
*/
iocbp->ioc_error = EPERM
bp->b_datap->db_type = M_IOCACK
qreply(q, bp)
return
case I_ERRNAK:
/*
* Negativ visszajelzest kell generalni ...
*/
iocbp->ioc_error = EPERM
bp->b_datap->db_type = M_IOCNAK
qreply(q, bp)
return
case I_SETHANG:
/*
* Kuldjunk fel egy visszajelzest, majd egy olyan uzenetet,
* amely M_HANGUP tipusu - be fog "fagyni" a stream.
*/
bp->b_datap->db_type = M_IOCACK
qreply(q, bp)
putctl(RD(q)->q_next, M_HANGUP)
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return
default:
/*
* Negativ visszajelzes - ismeretlen ioctl hivas miatt
*/
bp->b_datap->db_type = M_IOCNAK
qreply(q, bp)
return
}
}

8.3.7 Egy loopback drivert hasznalo program

A kovetkez} program bemutatja a loopback driver hasznalatat, es az egyes ioctl h vasok
o
eredmenyet is lehet vele tesztelni.
#include
#include
#include
#include

<errno.h>
<fcntl.h>
<stdio.h>
<sys/stropts.h>

/* Loopback driverben is definialt konstansok */
#define
#define
#define
#define

I_NOARG
I_ERRNAK
I_ERROR
I_SETHANG

#define IOBS
struct strioctl ioc

65
66
67
68
1024
/* Ide kerulnek az ioctl hivas opcioi */

main()
{
int fd, work
char buf IOBS]
if ((fd=open("/dev/lpbk", O_RDWR, 0777)) == -1) {
perror("nem tudtam megnyitni a device drivert\n")
exit(1)
}
printf("Milyen szoveget kuldjek el a loopback drivernek?")
if ((fgets(buf,IOBS,stdin)) == NULL) {
perror("fgets failed")
exit(1)
}
/* devicera iras es onnan olvasas */
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lp_wrt(fd,buf)
lp_read(fd)
/* Device ioctl teszt */
ioc.ic_cmd = I_ERRNAK
ioc.ic_timout = 0
ioc.ic_len = 0
ioc.ic_dp = NULL
if ((work = ioctl(fd,I_STR,&ioc)) < 0) {
perror("Ioctl rendszerhivas sikertelen")
}
printf("Visszateresi ertek ioctl rendszerhivasbol: %d\n",work)
lp_wrt(fd,buf)
lp_read(fd)
close(fd)
}
lp_wrt(fd, s)
int fd
char *mit
{
if (write(fd,mit,IOBS) < 0) {
perror("Hiba a wite rendszerhivasnal")
exit(1)
}
}
lp_read(fd)
int fd
{
char retbuf IOBS]
if (read(fd,retbuf,IOBS) < 0) {
perror("Hiba a read rendszerhivasnal")
exit(1)
}
printf("A beolvasott szoveg:%s\n",retbuf)
}

Megjegyzes: ne becsuljuk le a loopback driver lehet}segeit! Ezzel lehet}seg ny lik peldaul arra, hogy
o
o
egy exec rendszerh vas vegrehajtasa el}tt a ra elkuldott adatokat az exec rendszerh vassal vegrehajtott uj
o
program megkapja. (Ez azon mulik, hogy az exec nem zar le minden ledeszkriptort automatikusan, es a
STREAMS rendszer teljes egeszeben a UNIX kernelen belul helyezkedik el.) A STREAMS-nek ezt a tulajdonsagat hasznaltak ki akkor, amikor az ATT UNIX System V rendszeren a Berkeley sockets-eket implementaltak.
(STREAMS alapu device driverek fejlesztesenel ez a driver es a korabban bemutatott "debug" modul nagyon
nagy seg tseg!)
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8.4 Multiplexer driverek
Az eddig le rtakon k vul gyakran szukseg van arra, hogy az azonos helyr}l jov} adao o
tokat ne mindig ugyanazon az uton tovabb tsuk, hanem az adat jelleget}l fugg}en
o
o
(peldaul a benne tarolt protokoll-informaciok alapjan) mas-mas iranyba tovabb tsuk.
Ez gyakran szukseges peldaul halozati protokollok kesz tesenel. Erre a STREAMS
termeszetesen lehet}seget ad, es ezt a lehet}seget nevezzuk multiplexelesnek. A mulo
o
tiplexelest a STREAMS rendszerre ep tett multiplexer device driverekkel oldhatjuk
meg. (Ezeket a felep tesuk hasonlosaga miatt nevezik device drivereknek, de kuls}
o
periferiakkal leggyakrabban nem allnak kozvetlen kapcsolatban.) Bar a STREAMS egy
teljes eszkoztarat biztos t multiplexer driverek kesz tesere, megis gyakran felhasznaloi
szinten implementaljak a multiplexelest, mivel gy a megoldas gyakran egyszer}bb es
u
vilagosabb.

8.4.1 A multiplexerek elemei

A kovetkez} abran lathatjuk azokat az elemeket (az eredeti angol nyelv} nevukkel),
o
u
amelyekb}l a multiplexelt streameket lehet osszerakni.
o
Many-to-one multiplexer One-to-Many multiplexer Many-to-Many multiplexer
muxd

muxd

muxd

A many-to-one multiplexeles a klonolassal implementalhato. Ez hasznos lehet peldaul
egy terminalonkenti tobbablakos megjelen tesnel, ahol minden egyes fels} streamhez
o
kulon-kulon ablak van rendelve. A one-to-many multiplexeles eseten egy fels} streamr}l
o
o
kerulnek az adatok az also streamek valamelyikere. A many-to-many multiplexeles eseten
a fels} streamek valamelyiken erkez} adatok az also streamek kozul valamelyiken kerulnek
o
o
tovabb (es ford tva).

8.4.2 Egy multiplexer osszerakasa

A kovetkez}kben latni lehet, hogy egy halozatoknal is hasznalhato multiplexer kono
guraciot hogyan rakhatunk ossze. A halozatoknal gyakori problema az, hogy egy
csomopontban lev} gepben ket (kulonboz}) halozati kartya van (ez a gep kot ossze ket
o
o
alhalozatot). Peldaul legyen az egyik egy X.25, a masik pedig egy Ethernet kartya.
Ekkor az internet protokoll feladata az adatok megfelel} halozati kartyara kuldese, attol
o
fugg}en, hogy az egyes adatcsomagok rendeltetesi helye melyik alhalozatban van. Itt
o
a kovetkez}ket csinalhatjuk : meg kell nyitni az Ethernet es az X.25 kartya driveret
o
(ezek termeszetesen STREAMS device driverek nevuk legyen rendre /dev/ethernet ill.
/dev/x25), es meg kell nyitni az internet protokoll multiplexer drivert is (ennek neve
legyen a peldaban /dev/ip). Ezutan az IP multiplexert ossze kell kapcsolni (I_LINK
ioctl h vassal) a fenti ket masik driverrel. Ennek a C nyelv} kodja a kovetkez} :
u
o
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/* Konstansok miatt kell */

main()
/* STREAMS multiplexer config. */
{
int fdether,fdx25,fdip
int muxx25,muxether
/* Driverek megnyitasa : */
if ((fdether=open("/dev/ethernet",O_RDWR)) == -1 )
{ perror("/dev/ethernet") exit(1) }
if ((fdx25=open("/dev/x25",O_RDWR)) == -1 )
{ perror("/dev/x25") exit(1) }
if ((fdip=open("/dev/ip",O_RDWR)) == -1 )
{ perror("/dev/ip") exit(1) }
/* Multiplexer kiepitese : */
if (muxx25=ioctl(fdip,I_LINK,fdx25) < 0)
{ perror("I_LINK ioctl sikertelen") exit(2) }
if (muxether=ioctl(fdip,I_LINK,fdether) < 0)
{ perror("I_LINK ioctl sikertelen") exit(2) }
/* Ezutan az also driverek filedesc.-jai lezarhatok */
close(fdether)
close(fdx25)
pause()

/* Mindig fusson, nehogy a rendszer
lezarja a fileokat */
/* Ez nem kell most :
if (ioctl(fdip,I_UNLINK,muxether) < 0)
{ perror("I_UNLINK ioctl sikertelen") exit(2)
if (ioctl(fdip,I_UNLINK,muxx25) < 0)
{ perror("I_UNLINK ioctl sikertelen") exit(2)
*/

}
}

}

Az osszelinkeles utan az also streamek ledeszkriptorjaikra vonatkozo (ez esetben az
fdx25 es az fdether) barmilyen lem}velet (a close kivetelevel) hibaval fog befejez}dni,
u
o
vagyis a deszkriptorok hasznalhatatlanok lesznek, ezert erdemes ezeket lezarni. Ennek az
is a kovetkezmenye, hogy ha STREAMS modulokat akarunk peldaul az fdx25 ledeszkriptorhoz tartozo streamre rakni, akkor azt meg az osszelinkeles el}tt kell elintezni. Ha
o
ezutan az IP drivert egy masik programbol megnyitjuk es adatcsomagokat runk a ra
vonatkozo ledeszkriptorra, akkor az IP driver ezeket az adatokat szetosztja a ket also
driverre. Termeszetesen az IP drivert ugy kell meg rni, hogy felismerje az adatcsomagokbol azok rendeltetesi helyet.

8.4.3 Multiplexer ioctl-ek

A kovetkez}kben a multiplexerek kiep tesekor hasznalt STREAMS ioctl parancsokat, es
o
azok parameterezeset ismertetjuk (ld. ehhez korabbi A STREAMS rendszer vezerlese
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c m} reszt) :
u

: Osszekapcsol ket streamet, ahol fd parameter erteke a multiplexer driver
streamjenek a ledeszkriptorjat tartalmazza, az arg parameter pedig a multiplexer
driverhez kapcsolando stream ledeszkriptorjat tartalmazza. Sikeres vegrehajtas
eseten a h vas egy multiplexer ID ertekkel ter vissza, amit a multiplexer konguracio leep tesekor kell megadni, sikertelen vegrehajtas eseten -1-et ad vissza.
Hiba eseten az errno valtozo lehetseges ertekei :
{ EINVAL : Az fd stream nem multiplexelhet}, vagy valami egyeb okbol nem
o
vegrehajthato az osszekotes (ld. err}l reszletesebben a streamio(7) le rast).
o
{ EAGAIN : A vegrehajtaskor epp nem volt elegend} memoria.
o
{ ENXIO : Hangup-ot kapott az fd-vel megadott stream.
{ ETIME : Timeout. Hiaba vart a rendszer a multiplexer driver visszajelzesere.
Visszajelzes nem erkezett a multiplexert}l, pedig kellett volna.
o
I_LINK

Megjegyzes: az osszelinkeles ugy tortenik, hogy a multiplexer driver streamtab strukturajaban megadott
lower write illetve read queue informaciok be rodnak a driver ala linkelt stream stream-fej strukturajaba.
Ha alulrol egy uzenet elerkezik a driver ala belinkelt stream-fejhez, akkor az uzenetet megkapja a lower
read queue put rutinja, ami majd tovabbadhatja azt valamelyik fels} queuera.
o

: Szetkapcsol egy el}z}leg I_LINK h vassal osszekapcsolt multiplexer
oo
kon guraciot. Itt az fd parameter a multiplexerhez kapcsolt stream (multiplexer oldalarol nezve) ledeszkriptorjat, az arg parameter pedig az el}z} pontoo
ban eml tett multiplexer ID-et tartalmazza. (Ha a multiplexelest letrehozo program futasa befejez}dik, akkor minden altala letrehozott multiplexer kapcsolat
o
automatikusan megsz}nik.) Sikertelen vegrehajtas eseten -1-et ad vissza. Hiba
u
eseten az errno valtozo lehetseges ertekei :
{ EINVAL : Rossz parametereket adtunk meg fd-ben vagy arg-ban (ld. err}l
o
reszletesebben a streamio(7) le rast).
{ ENOSR : A vegrehajtaskor epp nem volt elegend} memoria (a STREAMSnek
o
fenntartott memoriateruleten).
{ ENXIO : Hangup-ot kapott az fd-vel megadott stream.
{ ETIME : Timeout. Hiaba vart a rendszer a multiplexer driver visszajelzesere.
Visszajelzes nem erkezett a multiplexert}l, pedig kellett volna.
o
I_UNLINK

8.4.4 Input/Output esemenyek gyelese

A STREAMS rendszer es a UNIX kernel lehet}seget ad tobb stream egyidej} gyelesere
o
u
is (ez lenyegeben mas operacios rendszerek polling lehet}segeinek felel meg). Fontos
o
ehhez egyreszt a poll rendszerh vas, masreszt az I_SETSIG STREAMS ioctl h vas.

Szinkron I/O polling

A poll rendszerh vas hasznalatakor a programban meg kell adni a gyelend} streamek
o
ledeszkriptorjait, es azt, hogy milyen esemenyre kell varni, es mennyi id} mulva
o
kovetkezzen be a timeout. A rendszerh vas kiadasa utan a program futasa leall addig,
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am g a timeoutkent megadott id} letelik vagy valamelyik kijelolt esemeny bekovetkezik.
o
Szintaxisa :
#include <stropts.h>
#include <poll.h>
int poll(fds,nfds,timeout)
struct pollfd fds ]
unsigned long nfds
int timeout

Az egyes parameterek jelentese a kovetkez} :
o
fds : Strukturatomb, amelynek minden egyes eleme megadja egy gyelend} stream
o
ledeszkriptorjat, a gyelend} esemenyeket, es ebbe a tombbe kerul a visszateres
o
pillanataban eszlelt esemeny. A pollfd struktura felep tese a kovetkez} :
o
int fd
short events
short revents

/* Filedeszkriptor */
/* Figyelendo esemenyek */
/* Eszlelt esemenyek */

Az egyes mez}k jelentese a kovetkez} :
o
o
{ fd : Egy megnyitott ( gyelend}) stream ledeszkriptorja.
o
{ events : A gyelend} esemenyeket tartalmazo bitmez}.
o
o
{ revents : A visszajelzett esemenyeket tartalmazo bitmez}.
o
A gyelesre kijelolhet} illetve a visszajelzett esemenyek a kovetkez}k kozul
o
o
kerulhetnek ki :
{ POLLIN : Egy uzenet (nem M_PCPROTO) kerult a stream-fej read queuejanak
az elejere. (A visszaadott esemenyek kozott ez es a POLLPRI egyszerre nem
fordulhat el}.)
o
{ POLLPRI : Egy magas prioritasu uzenet (M_PCPROTO) kerult a stream-fej read
queuejanak az elejere.
{ POLLOUT : A lefele men} streamra lehet rni (a rajta lev} adatok mennyisege
o
o
meg nem erte el a high water markot).
{ POLLHUP : Nem gyelesre kijelolhet} esemeny, csak a visszajelzett esemenyek
o
kozt fordulhat el}. Azt jelzi, hogy hangupot kapott a megfelel} stream.(A
o
o
visszaadott esemenyek kozott ez es a POLLOUT egyszerre nem fordulhat el}.)
o
{ POLLNVAL : Nem gyelesre kijelolhet} esemeny, csak a visszajelzett
o
esemenyek kozt fordulhat el}. Azt jelzi, hogy a hozza megadott ledeszkriptor
o
nem egy megnyitott streamre vonatkozik.
{ POLLERR : Nem gyelesre kijelolhet} esemeny, csak a visszajelzett esemenyek
o
kozt fordulhat el}. Azt jelzi, hogy egy hibauzenet (ld. M_ERROR uzenett pus)
o
erte el a stream-fejet.
nfds : Az ellen}rzend} streamek szama. (Az fds tomb merete.)
o
o
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timeout : A msec.-ban megadott timeout-id}. (Ha ez 0 , akkor a rendszerh vas
o
nem varakozik, csak megnezi, hogy van-e valami a stream-fejeknel, ha pedig -1,
akkor nem lesz timeout, a rendszerh vas tetsz}legesen sokaig fog varni.)
o
A visszateresi ertek jelentese a kovetkez} :
o
0 : Timeout.
x>0 : A visszateresi ertek : x egy pozitiv szam, es megadja, hogy hany streamen tortent valami. (Vagyis hany streamnek a revents mez}je tartalmaz nullatol
o
kulonboz} erteket.)
o
-1 : Hiba tortent. A hiba okarol az errno valtozoban talalunk informaciot. Ezek
lehetnek a kovetkez}k :
o
{ EAGAIN : Valamelyik kernelen beluli m}velet sikertelen volt, de a h vast
u
erdemes megegyszer megprobalni.
{ EFAULT : A parameterek a futo program c mtartomanyan k vulre mutatnak.
{ EINTR : A rendszerh vas vegrehajtasa alatt egy signal erkezett.
{ EINVAL : Hibas az nfds parameter erteke. (Vagy nullanal kisebb, vagy tullepi
a rendszerben megengedett limitet.)
A kovetkez} program bemutatja a poll rendszerh vas hasznalatat. A program mego
nyit ket streamet, az egyiket az Ethernet halozati driverhez,a masikat pedig az X.25
kontrollerhez, majd mindket streamen adatokra var. Ha az egyik streamen adatot kap,
akkor az ott bejov} adatokat a masik streamen elkuldi lefele. A programban az open
o
rendszerh vasnal az O_NDELAY ag azt jelzi, hogy ha a write rendszerh vas nem tudja
a szukseges mennyiseg} adatot a drivernek elkuldeni, akkor a write ne blokkoljon. A
u
peldaprogramban ha a write rendszerh vas nem tud minden adatot vissza rni, akkor a
felhasznalo hibakezel} rutinja usrherr() lesz megh vva.
o
#include <fcntl.h>
#include <poll.h>
main()
{
struct pollfd pollfds 2]
char buf 1024]
int count, i
if ((pollfds 0].fd = open("/dev/ethernet", O_RDWR | O_NDELAY)) < 0) {
perror("open /dev/ethernet sikertelen")
exit(1)
}
if ((pollfds 1].fd = open("/dev/x25", O_RDWR | O_NDELAY)) < 0) {
perror("open /dev/x25 sikertelen")
exit(2)
}
pollfds 0].events = POLLIN
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pollfds 1].events = POLLIN
while (1) {
if (poll(pollfds, 2, -1) < 0) {
perror("poll rendszerhivas sikertelen")
exit(3)
}
for (i=0 i<2 i++) {
switch (pollfds i].revents) {
case 0 :
/* Semmi sem volt */
break
case POLLIN :
/* Adat erkezett, kuldjuk vissza */
while ((count = read(pollfds i].fd, buf, 1024)) > 0)
if (write(pollfds 1-i].fd,buf,count) != count)
usrherr()
break
default:
perror("Erre az esemenyre nem szamitottam!")
exit(4)
break
} /* switch */
} /* for */
} /* while */
} /* main */
usrherr()
{
...
}

Aszinkron I/O polling - ioctl
A poll rendszerh vas mialatt egy esemenyre var, addig a rendszerh vast kiado program
futasa gyakorlatilag felfuggeszt}dik. Neha ez nem megengedhet}. Ekkor hasznalhatjuk
o
o
az I_SETSIG STREAMS ioctl rendszerh vast. Ez a h vas arra utas tja a kernelt, hogy
ha adat erkezik a megadott ledeszkriptoru stream stream-fejehez, akkor generaljon egy
SIGPOLL signalt.
A STREAMS ioctl harmadik parametere (korabban ezt arg jelolte) tartalmazza azokat az
esemenyeket, amelyek bekovetkezesekor signalt kell generalni. Ez a bitmez} a kovetkez}
o
o
ertekek osszerakasabol allhat (az osszerakas itt a bitenkenti VAGY m}veletet jelenti) :
u
S_INPUT : Egy alacsony prioritasu uzenet (nem M_PCPROTO) erkezett az addig ures
read queuera.
: Egy magas prioritasu uzenet (M_PCPROTO) erkezett a stream read
queuejara.
S_HIPRI

S_OUTPUT

tokat rni.

: A stream-fejt}l lefele indulo write queue mar nincs tele - lehet ra adao

174

FEJEZET 8. A UNIX SYSTEM V STREAMS PROGRAMOZASA

: Olyan STREAMS uzenet erkezett a stream-fejhez, amelynek az a feladata,
hogy
signalt kuldjon a programnak.
Ha az arg parameter erteke: 0, akkor a program ezutan nem kap a kernelt}l SIGPOLL
o
signalokat. Hiba eseten az errno valtozo lehetseges ertekei :
EINVAL : Az arg parameter erteke hibas. Ez a helyzet akkor is, ha az erteke nulla,
de a nulla ertek nem valtoztatna a jelenlegi allapoton.
EAGAIN : Pillanatnyilag nincs eleg STREAMS er}forras (memoria) a h vas
o
vegrehajtasahoz, de a h vast erdemes megismetelni, hatha sikerulni fog.
S_MSG
SIGPOLL

8.5 A kernel segedrutinjai
A kovetkez}kben ismertetett kernelrutinok a device driverek fejlesztesenel jol felo
hasznalhatok. Vannak egyeb kernel rutinok is (az itt felsoroltakon k vul), de azoknak egy
reszet az ATT a kes}bbi UNIX valtozatoknal nem biztos, hogy tovabbra is tamogatni
o
fogja.

8.5.1 STREAMS-speci kus h vasok

Az ebben a fejezetben ismertetett kernel rutinokat kizarolag STREAMS device driverekben hasznaljuk. Reszben azert, mert csak a STREAMS queuekon tudunk veluk dolgozni,
reszben pedig azert, hogy STREAMS driverjeink es moduljaink hordozhatoak legyenek.

allocb - lefoglal egy uzenetblokkot
struct msgb *
allocb(size)
register int size

Ez a fuggveny lefoglal egy uzenetblokkot a STREAMS adatteruleten, amelynek a
merete legalabb size byte. Az uzenet t pusa M_DATA lesz (ezt a programban kes}bb meg
o
lehet valtoztatni). Ha nincs eleg memoria, akkor az eredmeny egy NULL pointer.

bufcall - h vj meg egy eljarast, ha lesz szabad memoria
int bufcall(size, func, arg)
int size
void (*func)()
long arg

Ezzel az eljarassal lehet kerni a kernelt}l peldaul egy sikertelen allocb() h vas utan,
o
hogy ha felszabadul egy legalabb size meret} memoriaterulet (STREAMS uzenetek
u
szamara), akkor h vja meg a func parameterben megadott fuggvenyt arg parameterrel
(ez a (*func)(arg) fuggvenyh vast jelenti majd). Ha a kernel a keresunket tudomasul
vette, akkor a fuggveny visszateresi erteke 1 lesz, ha ezt a keresunket visszautas totta,
akkor 0 lesz a fuggveny visszateresi erteke.
FONTOS: Ha a megadott eljarast a kernel kes}bb majd megh vja, akkor sem lesz
o
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garantalva az, hogy az allocb() h vassal tudunk egy megadott meret} teruletet
u
lefoglalni, ugyanis a kernelben masoknak is szukseguk lehet memoriara, es lehet peldaul
az, hogy az epp felszabadult memoriat egy nagyobb prioritasu driver lefoglalja el}lunk.
o
Megjegyzes: nagyon gondoljuk meg, hogy mikor hasznaljuk ezt a kernel rutint, mert ezt a h vasi igenyt a
Release 3.2 UNIX rendszerekben meg nem tudjuk visszamondani. A veszely abban van, hogy el}allhat az a
o
helyzet, hogy egy STREAMS deviceot mar lezartunk, esetleg a queueja mar mas devicenak le lett foglalva, es
csak ezutan lesz valamikor megh vva a megadott fuggveny ...
Ezt a hianyossagot az ATT is eszrevette, ezert a Release 4.0 UNIX rendszerben mar van az unbufcall() kernel
rutin, amellyel egy korabban bejegyzett es a kernel altal elfogadott bufcall() h vas hatastalan thato.

canput - van-e eleg hely a streamben
int canput(q)
register queue_t *q

Ez a fuggveny ellen}rzi, hogy van-e meg hely a q message queueban. Ha a q queueo
nak nincs service rutinja, akkor a canput() fuggveny megkeresi az adott streamen soron
kovetkez} legels} olyan modult, amelynek van service rutinja. (Ha nem talal ilyen modo
o
ult, akkor a kereses a stream vegen fejez}dik be.) Vegul ha meg fer valami a q queueba,
o
akkor a fuggveny visszateresi erteke: 1 - ekkor lehet ujabb uzenetet rakni a queuera, ha
a queue betelt, akkor pedig 0 a visszateresi ertek, es ekkor a h vo blokkolva lesz. (A
blokkolas azt jelenti, hogy nem kerul ra a futasra kesz service folyamatok listajara.)

enableok - egy eddig inaktiv queue aktivizalasa
void enableok(q)
queue_t *q

A feladata egy korabban kiadott noenable() fuggveny hatastalan tasa, ami arra
utas totta a task schedulert, hogy a q queuet iktassa ki. (Ez nem jelenti azt, hogy a
qenable() kernel fuggvenyhez hasonloan a sor service rutinja egyb}l vegre is lesz hao
jtva!)

ushq - ush m} velet egy queuen
u
void flushq(q,flag)
register queue_t *q
int flag

Ez a fuggveny torol minden messaget a megadott q queuebol, es felszabad tja az
uzenetek altal lefoglalt teruletet a freemsg() fuggvennyel. A flag parameter erteke, es
ezek hatasa (ld. <sys/stream.h> include let) :
FLUSHDATA : csak az M_DATA, M_PROTO, M_PCPROTO es az
dobja el, a tobbit meghagyja.
FLUSHALL : Minden uzenetet kidob a megadott queuebol.

M_DELAY

uzeneteket
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freeb - egy darab uzenetblokk felszamolasa
void freeb(bp)
register struct msgb *bp

A freeb fuggveny felszabad tja a bp pointer altal mutatott uzenetblokk altal lefoglalt
memoriateruletet, a hozza tartozo adatblokkal egyutt. (Ha a hozza tartozo az adatblokk
db_ref reszenek erteke 1-nel nagyobb, akkor csak ez a szamlalo fog csokkenni, a lefoglalt
adatterulet nem lesz felszabad tva.)

freemsg - egy teljes uzenet felszamolasa
void freemsg(bp)
register mblk_t *bp

Vegigmegy a megadott message minden egyes uzenetblokkjan, es felszabad tja (ha
lehet) a message altal lefoglalt teljes memoriateruletet. Ha ez nem lehet (mert az adatblokk db_ref reszenek erteke 1-nel nagyobb), akkor ez a szamlalo eggyel csokkenni fog.
(A freemsg() fuggveny vegigmegy a message minden egyes blokkjan, es minden egyes
blokkot felszabad t a freeb() seg tsegevel.)

getmid - modul id. lekerdezese
ushort getmid(name)
char *name

A fuggveny eredmenye a megadott nev} modul modul azonos to szama. (Ha nincs
u
ilyen modul, akkor az eredmeny: 0).

getq - kovetkez} message leszedese a queuerol
o
mblk_t *getq(q)
register queue_t *q

Leszedi a kovetkez} uzenetet (ha van) a q message queuerol. A fuggveny egy pointert
o
ad vissza, ami a leszedett message c met tartalmazza. Ha nincs mar message a queuen,
akkor a fuggveny visszateresi erteke NULL pointer lesz, es a rendszer beall t a queue
adatstrukturajaban egy QWANTR aget, ami azt jelzi, hogy a queuerol olvasni akarnak.
Ha ilyen allapotban egy uzenet erkezik a queuera, akkor a kernel a qenable() fuggveny
megh vasaval automatikusan ujraind tja a service rutint.
Ha a getq() rutin leszedett egy uzenetet a q message queuerol, es ezutan a queuen
lev} uzenetek osszhossza kisebb, mint a queuehoz megadott low water mark ertek, es a
o
queuera mar probaltak korabban uj uzenetet rakni, de ez sikertelen volt, akkor a q queue
mogotti sor service rutinja a qenable() fuggveny megh vasaval ujra el lesz ind tva.

noenable - queue inaktivizalasa
void noenable(q)
queue_t *q
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A megadott q queuet inaktiv allapotba hozza - a STREAMS service scheduler
nem adja ennek a sornak a service rutinjara tobbet a vezerlest. (Inverz m}velete: az
u
enableok() fuggveny.)

OTHERQ - megadja a queue parjat
#define OTHERQ(q)

((q)->q_flag&QREADR? (q)+1 : (q)-1)

A makro eredmenye a q queue parjara mutato pointer. (Ha a q a read queue, akkor az
eredmeny a hozza tartozo write queuera mutato pointer ha q egy write queuera pointer,
akkor az eredmeny a read queuera pointer.)

putctl - kontroll-uzenet tovabb tasa
int putctl(q, type)
queue_t *q
int type

A putctl() fuggveny lefoglal egy uzenet szamara az allocb() kernelh vas
seg tsegevel memoriat, az uzenet t pusat beall tja a type parameterben megadottra, majd
megh vja a q parameter altal mutatott queue put rutinjat. A fuggveny visszateresi erteke
1, ha minden rendben ment. Nulla akkor lehet a visszateresi ertek, ha a rendszer nem
tudott lefoglalni az uzenetblokk szamara memoriat, vagy a type parameter erteke az
M_DATA, M_PROTO, M_PCPROTO, vagy M_DELAY ertekek egyike.

putbq - uzenet visszarakasa a sorba
int *putbq(q, bp)
register queue_t *q
register mblk_t *bp

A putbq() fuggveny a bp altal mutatott uzenetet visszarakja a q altal mutatott queue
elejere. (A queuban legel}bbre kerulnek a magas prioritasu uzenetek, a normal prioritasu
o
uzenetek pedig a magas prioritasu uzenetek moge, de a korabban mar ott lev} alacsony
o
prioritasu uzenetek ele kerulnek.) A service rutin soha ne rakjon vissza magas prioritasu

uzenetet a sajat queuejaba, mert ez vegtelen ciklust eredmenyezne a kernelen belul!

Sikeres vegrehajtas eseten a fuggveny visszateresi erteke: 1, sikertelen vegrehajtas eseten
a visszateresi ertek 0 lesz.

putnext - egy uzenetet a kovetkez} queuera rak
o
#define putnext(q,mp) ((*(q)->q_next->q_qinfo->qi_putp)((q)->q_next,(mp)))

A putnext() egy makro, amely a q utan kozvetlenul kovetkez} queue put() rutinjat
o
h vja meg, es atadja neki az mp altal mutatott uzenetet.
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putq - egy megadott uzenetet valamelyik queuera rakja
int *putq(q, bp)
register queue_t *q
register mblk_t *bp

A putq() fuggveny a q parameterben meghatarozott queura atadja az mp altal mutatott uzenetet.

qenable - queue aktivizalasa
void qenable(q)
register queue_t *q

Ez a fuggveny a q parameter altal meghatarozott sort a STREAMS schedulernek arra
a listajara rakja, amely a futasra kesz sorok adatait tartalmazza. Ez azt jelenti, hogy az
adott queue service rutinja rovid id}n belul ujbol futni fog.
o

qreply - uzenet visszakuldese ellentetes iranyban
void *qreply(q, bp)
register queue_t *q
mblk_t *bp

Ez a fuggveny meghatarozza a q queue parjat (a lefele men} streamnek a parja a felfele
o
men}, ill. ford tva), es azon a putnext() makro m}kodesehez hasonloan visszakuldi a
o
u
bp pointer altal meghatarozott uzenetet. Ezt a fuggvenyt szoktak hasznalni az M_IOCTL
uzenetekre kuldend} valasz visszakuldesere.
o

RD - megadja a read queuet
#define RD(q)

((q)-1)

A makro parametere (q) egy write queuera mutato pointer, eredmenye pedig a q
queue parjara (vagyis a read queuera) mutato pointer. Ez a m}velet azert ilyen egyszer},
u
u
mert a kernel a queuekat nem egyenkent foglalja le, hanem parosaval. Az alacsonyabb
memoriac men van a read queue, a magasabbon pedig a write queue.

splstr - atall tja az interrupt prioritasi szintet
#define splstr()

spltty()

Az splstr() makro az spltty() kernelh vas seg tsegevel beall tja a processzor interrupt prioritasi szintjet a STREAMS driverek es modulok interrupt prioritasi szintjere,
a kritikus szakaszok vedelme erdekeben. Ez azt jelenti, hogy az eppen futo driver
m}kodeset mas driverek vagy modulok nem tudjak megszak tani. Ez a rutin visszateresi
u
ertekkent az addigi processzor interrupt prioritasi szintet adja. A kritikus szakasz vegen
az splx() kernelh vas seg tsegevel vissza kell all tani a processzor interrupt prioritasi
szintjet az el}z} ertekre. Ezt a rutint csak igen indokolt esetben hasznaljuk! Megjeoo

gyzes: az Intel 80386-os UNIX rendszerek eseten ez altalaban IPL=7 szintnek felel meg, es ekkor sem a soros
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vonalakrol jov} megszak tasok, sem az oramegszak tasok nem lesznek megengedve. Mivel a rendszerora is le
o
lesz tiltva, ezert csak olyan rutinokat vedjunk gy, aminek a vegrehajtasa nem igenyel tobb id}t, mint ket
o
orainterrupt kozti id}.
o

unlinkb - egy uzenet els} blokkjat torli
o
mblk_t *
unlinkb(bp)
register mblk_t *bp

Az unlinkb() fuggveny elvalasztja a bp parameter altal mutatott uzenet els}
o
uzenetblokkjat a mogotte lev} blokkoktol, es egy pointert ad vissza az uzenet mego
marado reszere. Az eredmenye NULL pointer lesz, ha nem maradt tobb uzenetblokk
az uzenetben. (Az els} uzenetblokk nem lesz automatikusan felszabad tva, gy ez a proo
gramozo feladata marad.)

WR - megadja a write queuet
#define WR(q)

((q)+1)

A WR makro parametere (q) egy read queuera mutato pointer, eredmenye pedig a q
queue parjara (vagyis a hozza tartozo write queuera) mutato pointer.

8.5.2 Altalanosan hasznalhato kernel rutinok

A kovetkez}kben ismertetett kernel h vasok mind a hagyomanyos, mind pedig a
o
STREAMS device driverek kesz tesenel jol hasznalhatoak. Ezek hasznalata gyakran
szukseges, de ronthatjak a program hordozhatosagat. (Peldaul a Release 4.0 UNIX
modos tott major/minor device number kezelese miatt ha atterunk erre a UNIX rendszerre, akkor modos tani kell a drivereknek azt a reszet, amely a minor() vagy major()
rutinokat hasznaljak. Ez termeszetesen nem nagy munka - baj csak akkor van, ha ezt
elfelejtjuk.)

cmn err - driver hibauzenetek ki rasa konzolra
#include "sys/cmn_err.h"
int cmn_err(severity, format, arguments)
char *format
int severity, arguments

Figyelmeztetes: egy hibasan megadott severity ertek a rendszert azonnal panic
allapotba viszi.

Az egyes parameterek jelentese a kovetkez} :
o
severity : Negy kulonboz} erteke lehet a hiba sulyossagatol fugg}en :
o
o
{ CE_CONT : Ez kb. egy printf() h vassal egyenertek} - nem r az uzenet ele
u
semmit.
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{

: Ki rja a parameterekben megadott szoveget, egy NOTICE: uzenetet
kovet}en.
o
{ CE_WARN : Ki rja a parameterekben megadott szoveget, egy WARNING: uzenetet
kovet}en.
o
{ CE_PANIC : Ki rja a parameterekben megadott szoveget, egy PANIC: uzenetet
kovet}en, es a rendszert panic allapotba viszi. (Ekkor a UNIX azonnal leall,
o
es egy memoria dump kerul a swap egysegre.)
format : Egy printf()-hez hasonlo formatumot lehet itt megadni. A stringben
megadhato adatformatumok :
{ %b : Ket hexadecimalis szamjegy (egy byte)
{ %c : Karakteres
{ %d : El}jeles decimalis szam
o
{ %o : El}jel nelkuli oktalis szam
o
{ %s : String (karakter-pointer)
{ %x : Hexadecimalis (vezet} nullakkal egyutt rja ki)
o
Mez}hossz megadasa nem megengedett (peldaul a %9d nem adhato meg
o
formatumkent). Ilyen modon nem csak a konzolra rhatunk ki hibauzenetet. Azt,
hogy a ki rt uzenet hova keruljon,a format parameterben megadott uzenet els}
o
karaktere hatarozza meg. Ha ott az els} karakter egy felkialtojel (vagyis: !), akkor
o
az uzenet nem kerul ki a konzolra. Egy bels} bu erben lesz tarolva, amit a crash
o
rendszerprogram seg tsegevel elemezhetunk. Ha az els} karakter egy kalap (vagyis:
o
^), akkor az uzenet ki lesz rva a konzolra, de nem kerul bele a fent eml tett bu erbe.
Ha ezekt}l elter} karakterrel kezd}dik az uzenet, akkor a rendszer mind a konzolra,
o
o
o
mind a bels} bu erebe ki rja azt. Ha a severity ertek nem CE_CONT, akkor az
o
uzenet ki rasa utan a rendszer meg egy ujsor karaktert is ki r, m g CE_CONT severity
ertek megadasa eseten ilyen ujsor karakter nem lesz automatikusan ki rva.
CE_NOTE

Megjegyzes: A ki rando adatok formatumanak megadasa a kulonboz} UNIX rendszerekben elter} lehet,
o
o
ezert ha az egyik UNIX rendszerre keszult STREAMS driverunket atvisszuk egy masfajta UNIX rendszerre, akkor nezzunk ennek utana a UNIX le rasban, nehogy valami ilyen jelleg} hibat kovessunk el.
u

arguments : Opcionalis argumentek, amit ezzel a rutinnal ki akarunk iratni. A
format parameterrel ezek az argumentumok osszhangban legyenek.

major - megadja a major device numbert
#include "sys/sysmacros.h"
int major(dev)
dev_t dev

Ez a kernel h vas arra szolgal, hogy az open() rutinnak atadott major es minor device
numbert tartalmazo parameterb}l kinyerje a major device numbert. Megvalos tasa egyes
o
UNIX rendszrekben makroval tortenik. A dev parameterben leggyakrabban az open()
rutinnak atadott azonos nev} parameter lesz megadva. Megjegyzes:Az ISC 3.2 UNIX rendszer
u

alatt a dev t t pus short integer t pust jelol.
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minor - megadja a minor device numbert
#include "sys/sysmacros.h"
int minor(dev)
dev_t dev

A minor() kernel h vas arra szolgal, hogy az open() rutinnak atadott major es minor
device numbert tartalmazo parameterb}l kinyerje a minor device numbert. Megvalos tasa
o
egyes UNIX rendszrekben makroval tortenik.

8.6 Kerdesek
1. Megvaltozhat-e a bemutatott STREAMS loopback drivernel az uzenetek visszaadasi sorrendje a bemen} sorrendhez kepest? Ha megvaltozhat, akkor jelentheto
e ez problemat mondjuk az Internet Protokoll (IP) implementalasakor?
2. Modos tsuk a korabban bemutatott debug modult ugy, hogy ne csak az uzenetek
tartalmat rja ki, hanem minden egyes uzenet elejen rja ki annak t pusat is!
3. A STREAMS loopback driverunk felfele halado (read) queuejanak van egy service
rutinja, es ahhoz a queuehoz nincs de nialva put rutin. Mikor lesz megh vva a
service rutin a read queue oldalarol? (Tanacs: Gondoljon arra, hogy mit csinal a
getq() kernel rutin!)
4. Mit gondol, hogy egy I LINK utan miert lesz a felhasznaloi program szamara az
a stream hasznalhatatlan, amit a multiplexer ala linkeltunk? (Tanacs: Gondolja
meg, hogyan m}kodik az I LINK ioctl h vas!)
u
5. B}v tsuk ki a STREAMS loopback driverunket, hogy modulkent is lehessen
o
hasznalni!
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8.7 Ajanlott irodalom
1. M. Ben-Ari: Principles of Concurrent Programming
Englewood Cli s, Prentice-Hall International, 1982
A konyv kivalo st lusban alapos bevezetest nyujt a parhuzamos programozasba. Ismerteti a gyakrabban hasznalt szinkronizacios lehet}segeket (szemaforok, uzenetek
o
atadasa, randevuk, ...), es ismertebb parhuzamos algoritmusokat is bemutat.
2. Stephen R. Bourne: The UNIX System Reading, Addison-Wesley, 1982
A konyv egy altalanos bevezetest nyujt a UNIX rendszer programozasahoz, ismerteti a UNIX kornyezetet, amit a felhasznalo a gep ele leulve lat.
3. Brian W. Kernighan, Rob Pike: The UNIX Programming Environment Englewood Cli s, Prentice-Hall, 1984 (Magyarul is megjelent)
A konyvben a UNIX rendszerek "kozos resze" (Version 7 UNIX) van reszletesen
(felhasznaloi es programozoi szempontok szerint) ismertetve. A konyvet azert
is erdemes elolvasni, mert nehany angol kifejezest nagyon lehetetlen modon
ford tottak benne magyarra, es ez tobbszor is megmosolyogtatja az olvasot (azt
persze en (Cs.B.) is elismerem, hogy nehany kifejezesnek nagyon nehez magyar
ford tasat talalni, lehet, hogy nehol nekem sem sikerult megtalalnom az "igazit").
4. Brian W. Kernighan, Dennis Ritchie: The C Programming Language Englewood
Cli s, Prentice-Hall, 1978
Ez a konyv ismerteti a legjobban a C nyelvet (nemcsak a UNIX kornyezetben
hasznalhato). A konyv megjelent magyarul, es hasznos mindenki szamara.
5. A. S. Tanenbaum: Operating Systems Design and Implementation Englewod
Cli s, Prentice-Hall, 1987
A konyv bemutatja az operacios rendszerek felep teset, a kovetkez} pontokra
o
bontva: rendszerh vasok (Version 7 UNIX alapjan), processzek, input/output,
memoriakezeles es a fajlrendszerek. Kiegesz teskent benne van egy UNIX-szer}
u
operacios rendszernek a teljes forraskodja kommentekkel es a tervezesenel meghozott dontesekkel es azok indoklasaval egyutt. (MINIX a rendszer neve).
6. A. S. Tanenbaum: Szam togep-halozatok Novotrade Kiado Kft. - Prentice-Hall
kozos kiadvany, 1992
A konyv az OSI halozati referenciamodellen keresztul ad eleg absztrakt modellt a
szam togepes halozatokrol (mind a 7 OSI szintet nagyon reszletesen ismertetve). A
magyar fordts itt egeszen jol olvashato. A konyv nem targyalja nagyon reszletesen
az operacios rendszer es a halozati szintek kozotti interfeszt (mint pl. a socket
rendszer), ezert csak ez alapjan nagyon nehez lenne "az els}" halozati alkalamzast
o
elkesz teni.
7. AT&T Bell Labs.: UNIX System V Release 4.0 Programmer's Guide AT&T Bell
Labs.: UNIX System V Release 4.0 Programmer's Reference Manual (Prentice-Hall
kiadvanyok)
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A UNIX programozoknak nyujtott lehet}segeit ismertetik.
o
Az el}bbi
o
"szakacskonyvi" szinten, m g az utobbi a rendszerh vasok reszletes speci kaciojat
tartalmazza. (Ez utobbi nem igazan olvasmanyos.)
8. Maurice Bach: The Design of the UNIX Operating System Englewood Cli s,
Prentice-Hall, 1987
Kifejtett temak (a System V UNIX alapjan): kernel, bu er cache, fajlrendszerek,
folyamatok, memoriakezeles es az I/O, es az IPC.
9. Myril Clement Shaw, Susan Soltis Shaw: UNIX Internals (A systems operation
handbook) TAB BOOKS, 1987 ISBN 0-8306-2951-3
Ez a konyv is a UNIX operacios rendszer bels} felep teset mutatja be kulonfele
o
szempontokbol: ismerteti a fajlrendszert, i-node-okat, a UNIX folyamatainak a
fogalmat, az I/O-t es az eszkozmeghajtokat. Kiegesz teskent tartalmaz nehany fejezetet, melyben osszefoglalja a UNIX rendszerh vasait, a fontosabb UNIX parancsokat valamint tartalmaz egy rovid osszehasonl tast, melyben az AT&T es a Berkeley UNIX-ot hasonl tja ossze.
10. S. Le er, M. McKuisk, M. Karels, J. Quaterman: The Design and Implementation of the 4.3BSD UNIX Operating System Addison-Wesley, 1989
A konyv a 4.3BSD UNIX alapjan bemutatja a UNIX rendszer felep teset, szerkezetet. A konyv a temat nagyon reszletesen kifejti. A szerz}i maguk is reszt
o
vettek a 4.3BSD rendszer fejleszteseben.

